| Age | Commit message (Collapse) | Author |
|---|
|
This reverts commit ab30509b25d54dac99294b76ba03fd49c3d2c946.
As in T6152 there seem to be some NICs that have a non working implementation
of reading the EEE registers. Remove this feature in the meantime until there
is a less exploding solution hindering boards to boot.
Return to Kernel defaults by removing this code path.
(cherry picked from commit 946f93778f15f4af9f31cd5b164efcd931693635)
|
|
settings
(cherry picked from commit 5ee89f46096626ca8aac37da9237635e3d17766a)
|
|
Feature detection is used to see if certain offload settings are available on
the given NIC.
(cherry picked from commit 63ccdc5125e19f8737bf1445938998bef803d1bd)
|
|
(cherry picked from commit b984cf8d179cf3d4b16e7f3e5cf94f822055cb04)
|
|
EEE enabled status is on the 2nd line of ethtool output and not the 3rd. Subsequently, reading the 3rd line was causing an out-of-bounds access for the bnx2x driver as well.
(cherry picked from commit 775348a4cda34e6be16454d43c77b525e57c4e47)
|
|
VyOS is a routing (packet pushing) platform, thus supporting EEE which
potentially causes issues is not a good idea. Some recent Intel drivers enable
EEE by default, thus we will disable this for every NIC supporting EEE.
(cherry picked from commit ab30509b25d54dac99294b76ba03fd49c3d2c946)
|
|
|
|
* T5195: move run, cmd, call, rc_cmd helper to vyos.utils.process
* T5195: use read_file and write_file implementation from vyos.utils.file
Changed code automatically using:
find . -type f -not -path '*/\.*' -exec sed -i 's/^from vyos.util import read_file$/from vyos.utils.file import read_file/g' {} +
find . -type f -not -path '*/\.*' -exec sed -i 's/^from vyos.util import write_file$/from vyos.utils.file import write_file/g' {} +
* T5195: move chmod* helpers to vyos.utils.permission
* T5195: use colon_separated_to_dict from vyos.utils.dict
* T5195: move is_systemd_service_* to vyos.utils.process
* T5195: fix boot issues with missing imports
* T5195: move dict_search_* helpers to vyos.utils.dict
* T5195: move network helpers to vyos.utils.network
* T5195: move commit_* helpers to vyos.utils.commit
* T5195: move user I/O helpers to vyos.utils.io
|
|
Add initial configuration mode for VPP (PoC)
set vpp cpu corelist-workers '2'
set vpp cpu main-core '1'
set vpp interface eth1 num-rx-desc '256'
set vpp interface eth1 num-rx-queues '512'
set vpp interface eth1 num-tx-desc '256'
set vpp interface eth1 num-tx-queues '512'
set vpp interface eth1 pci '0000:02:00.0'
set vpp interface eth1 rx-mode 'polling'
set vpp interface eth2 pci '0000:08:00.0'
Limitation:
- 'set vpp interface ethX pci auto' works only per first
commit, then interface detached from default stack and creates
tun interface 'ethX' to communicate with default stack. In this
case we can't get PCI address via ethtool for 'tun' interfaces.
But we can set pci address manualy.
- Interface sync between default stack and VPP-DPDK stack
After vpp change it doesn't trigger iproute2 for changes
(should be written later)
I.e. if we change something in vpp per each commit it restarts
vpp.service it gets empty interface config as we don't configure vpp
directly and it should be configured via iproute2
But then if we do any change on interface (for example description)
it gets IP address, MTU, state, etc.
|
|
change speed/duplex settings
This is the same problem as reported in T4297. By definition it is not possible to change speed and duplex settings at SR-IOV virtual functions driven by ixgbevf driver. I think the solution is the same as well, that is to add 'ixgbevf' into _drivers_without_speed_duplex_flow in /usr/lib/python3/dist-packages/vyos/ethtool.py. It fixed the problem for me with Intel x520 NICs.
|
|
Commit f2ecc9710d49 ("ethernet: T3891: honor auto-negotiation support per NIC")
added an if statement that always evaluated to True.
|
|
Not all drivers/NICs or combination of NIC + transceiver support auto-
negotiation. The current auto-negotiation capability is evaluated and taken
into account when applying spped/duplex settings. If auto-negotiation is
not supported - we skip the setting to avoid errors during configuration.
|
|
Exclude interfaces with 'veth' driver from duplex and speed check
|
|
The previous solution did not work for drivers that were no modules.
e.g compiled with a kernel config set to CONFIG_VIRTIO_NET=y
|
|
|
|
The iavf, ice, and i40e drivers do not support speed, flow, or duplex control using ethtool.
As a result, interface configuration changes fail to commit when using those drivers.
This patch fixes that by correctly marking those drivers as not supporting those controls.
|
|
|
|
In addition to commit 0b414bcd ("vyos.ethtool: T3874: do not throw exception
if adapter has issues with autoneg") we should also not care too strict when
locating the driver name.
This might cause false positives.
|
|
Instead of throwing an exception when an adapters autoneg capabilities can not
be detected, just pretend it does not support autoneg.
|
|
(cherry picked from commit 3037661951d0e5d1f6264f886781b7ddc019329e)
|
|
Move the two implementations to get the driver name of a NIC from ethernet.py
and ethtool.py to only ethtool.py.
(cherry picked from commit 07840977834816b69fa3b366817d90f44b5dc7a7)
|
|
(cherry picked from commit 1572edd2cef355710d1129907d3e49451a6c31d4)
|
|
Commit 29082959 ("ethernet: T3163: only change ring-buffer settings if
required") added a delta-check code for the ring buffer values, unfortunately
this was never properly evaluated as str() and int() got compared resulting
always in an unequal result.
|
|
It makes no sense to have a parser for the ethtool values in ethtool.py
and ethernet.py - one instance ios more then enough!
|
|
Only update the RX/TX ring-buffer settings if they are different from the ones
currently programmed to the hardware. There is no need to write the same value
to the hardware again - this could cause traffic disruption on some NICs.
|
|
It makes no sense to have a parser for the ethtool value sin ethtool.py
and ethernet.py - one instance ios more then enough!
|
|
Not all interface drivers have the ability to change the speed and duplex
settings. Known drivers with this limitation are vmxnet3, virtio_net and
xen_netfront. If this driver is detected, an error will be presented to the
user.
|
|
This makes understanding the code easier what is "really" called without
opening the man page.
|
|
Deprecated in the Linux Kernel by commit 08a00fea6de277df12ccfadc21 ("net:
Remove references to NETIF_F_UFO from ethtool.").
(cherry picked from commit f5e46ee6cc2b6c1c1869e26beca4ccd5bf52b62f)
|
|
|
|
Add a new method which supports checking if the desired speed and duplex
setting is actually supported by the underlaying network interface card.
>>> from vyos.ethtool import Ethtool
>>> tmp = Ethtool('eth0')
>>> tmp.check_speed_duplex('100', 'full')
False
>>> tmp.check_speed_duplex('1000', 'full')
True
|
|
|
|
Commit d22f97af ("vyos.ethtool: T3163: rename unused methods for offload
validation") reworked the entire class on how data should be presented to the
user, but forgot to drop the is_fixed_lro() method.
|
|
|
|
Ethtool version used on Debian Bullseye changed the output format from 0 -> n/a.
As we are only interested in the tx/rx keys we do not care about RX Mini/Jumbo.
|
|
|
|
In addition to commit cf1156a60e ("ethernet: T3163: probe driver for maximum
rx/tx ring-buffer size") this extends the logic in a way as not every driver
supports setting the buffers at all so it will properly error out.
When invoking "ethtool -g" both stdout and stderr are captured and no exception
is raised if it's an unsupported driver feature. The verify() section will
inform the user about the illegal operation.
|
|
|
|
This helper class could be used to interact and retrieve information from
ethtool. It is not used so far in production code.
|
