| 1c5c6cd8 | 03-May-2022 |
Huisong Li <[email protected]> |
net/bonding: fix slave stop and remove on port close
All slaves will be stopped and removed when closing a bonded port.
But the while loop can not end if both rte_eth_dev_stop and
rte_eth_bond_slave
net/bonding: fix slave stop and remove on port close
All slaves will be stopped and removed when closing a bonded port.
But the while loop can not end if both rte_eth_dev_stop and
rte_eth_bond_slave_remove fails, runs infinitely.
This is because the skipped slave port counted in both function failures
but it should be counted only one.
Fixing by not continue to process in the loop after first failure.
Fixes: fb0379bc5db3 ("net/bonding: check stop call status")
Cc: [email protected]
Signed-off-by: Huisong Li <[email protected]>
Signed-off-by: Min Hu (Connor) <[email protected]>
show more ...
|
| b3eaaf1d | 15-Feb-2022 |
Junjie Wan <[email protected]> |
net/bonding: fix slaves initializing on MTU setting
If a initial process for the bonding device is like:
rte_eth_dev_configure
rte_eth_dev_set_mtu
queue setup and start, etc.
Pass the vdev args to
net/bonding: fix slaves initializing on MTU setting
If a initial process for the bonding device is like:
rte_eth_dev_configure
rte_eth_dev_set_mtu
queue setup and start, etc.
Pass the vdev args to application, and init bonding device only.
-a 0000:af:00.0 --vdev="net_bonding0,mode=2,slave=0000:af:00.0"
It will fail and complain for the slave device
"Port 0 must be configured before MTU set"
Test can be reproduced with ovs.
Fixes: b26bee10ee37 ("ethdev: forbid MTU set before device configure")
Cc: [email protected]
Signed-off-by: Junjie Wan <[email protected]>
Tested-by: Ferruh Yigit <[email protected]>
Acked-by: Min Hu (Connor) <[email protected]>
show more ...
|
| 814e79f3 | 28-Jan-2022 |
Min Hu (Connor) <[email protected]> |
net/bonding: fix reference count on mbufs
In bonding Tx broadcast mode, Packets should be sent by every slave,
but only one mbuf exits. The solution is to increment reference count
on mbufs, but it
net/bonding: fix reference count on mbufs
In bonding Tx broadcast mode, Packets should be sent by every slave,
but only one mbuf exits. The solution is to increment reference count
on mbufs, but it ignores multi segments.
This patch fixed it by adding reference for every segment in multi
segments Tx scenario.
Fixes: 2efb58cbab6e ("bond: new link bonding library")
Cc: [email protected]
Signed-off-by: Min Hu (Connor) <[email protected]>
show more ...
|
| ac5341f5 | 28-Jan-2022 |
Min Hu (Connor) <[email protected]> |
net/bonding: fix promiscuous and allmulticast state
Currently, promiscuous or allmulticast state of bonding port will not be
passed to the new primary slave when active/standby switch-over. It
cause
net/bonding: fix promiscuous and allmulticast state
Currently, promiscuous or allmulticast state of bonding port will not be
passed to the new primary slave when active/standby switch-over. It
causes bugs in some scenario.
For example, promiscuous state of bonding port is off now, primary slave
(called A) is off but secondary slave(called B) is on.
Then active/standby switch-over, promiscuous state of the bonding port
is off, but the new primary slave turns to be B and its promiscuous
state is still on.
It is not consistent with bonding port. And this patch will fix it.
Fixes: 2efb58cbab6e ("bond: new link bonding library")
Fixes: 68218b87c184 ("net/bonding: prefer allmulti to promiscuous for LACP")
Cc: [email protected]
Signed-off-by: Min Hu (Connor) <[email protected]>
show more ...
|
| 1bb4a528 | 18-Oct-2021 |
Ferruh Yigit <[email protected]> |
ethdev: fix max Rx packet length
There is a confusion on setting max Rx packet length, this patch aims to
clarify it.
'rte_eth_dev_configure()' API accepts max Rx packet size via
'uint32_t max_rx_p
ethdev: fix max Rx packet length
There is a confusion on setting max Rx packet length, this patch aims to
clarify it.
'rte_eth_dev_configure()' API accepts max Rx packet size via
'uint32_t max_rx_pkt_len' field of the config struct 'struct
rte_eth_conf'.
Also 'rte_eth_dev_set_mtu()' API can be used to set the MTU, and result
stored into '(struct rte_eth_dev)->data->mtu'.
These two APIs are related but they work in a disconnected way, they
store the set values in different variables which makes hard to figure
out which one to use, also having two different method for a related
functionality is confusing for the users.
Other issues causing confusion is:
* maximum transmission unit (MTU) is payload of the Ethernet frame. And
'max_rx_pkt_len' is the size of the Ethernet frame. Difference is
Ethernet frame overhead, and this overhead may be different from
device to device based on what device supports, like VLAN and QinQ.
* 'max_rx_pkt_len' is only valid when application requested jumbo frame,
which adds additional confusion and some APIs and PMDs already
discards this documented behavior.
* For the jumbo frame enabled case, 'max_rx_pkt_len' is an mandatory
field, this adds configuration complexity for application.
As solution, both APIs gets MTU as parameter, and both saves the result
in same variable '(struct rte_eth_dev)->data->mtu'. For this
'max_rx_pkt_len' updated as 'mtu', and it is always valid independent
from jumbo frame.
For 'rte_eth_dev_configure()', 'dev->data->dev_conf.rxmode.mtu' is user
request and it should be used only within configure function and result
should be stored to '(struct rte_eth_dev)->data->mtu'. After that point
both application and PMD uses MTU from this variable.
When application doesn't provide an MTU during 'rte_eth_dev_configure()'
default 'RTE_ETHER_MTU' value is used.
Additional clarification done on scattered Rx configuration, in
relation to MTU and Rx buffer size.
MTU is used to configure the device for physical Rx/Tx size limitation,
Rx buffer is where to store Rx packets, many PMDs use mbuf data buffer
size as Rx buffer size.
PMDs compare MTU against Rx buffer size to decide enabling scattered Rx
or not. If scattered Rx is not supported by device, MTU bigger than Rx
buffer size should fail.
Signed-off-by: Ferruh Yigit <[email protected]>
Acked-by: Ajit Khaparde <[email protected]>
Acked-by: Somnath Kotur <[email protected]>
Acked-by: Huisong Li <[email protected]>
Acked-by: Andrew Rybchenko <[email protected]>
Acked-by: Konstantin Ananyev <[email protected]>
Acked-by: Rosen Xu <[email protected]>
Acked-by: Hyong Youb Kim <[email protected]>
show more ...
|
| 6b1a001e | 22-Sep-2021 |
Chengchang Tang <[email protected]> |
net/bonding: fix RSS key length
Currently the hash_key_size information has not been set. So, apps can
not get the key size from dev_info(), this make some problem.
e.g, in testpmd, the hash_key_si
net/bonding: fix RSS key length
Currently the hash_key_size information has not been set. So, apps can
not get the key size from dev_info(), this make some problem.
e.g, in testpmd, the hash_key_size will be checked before configure
or get the hash key:
testpmd> show port 4 rss-hash
dev_info did not provide a valid hash key size
testpmd> show port 4 rss-hash key
dev_info did not provide a valid hash key size
testpmd> port config 4 rss-hash-key ipv4 (hash key)
dev_info did not provide a valid hash key size
In this patch, the meaning of rss_key_len has been modified. It only
indicated the length of the configured hash key before. Therefore,
its value depends on the user's configuration. This seems unreasonable.
And now, it indicates the minimum hash key length required by the
bonded device. Its value will be the shortest hash key among all slave
drivers.
Fixes: 734ce47f71e0 ("bonding: support RSS dynamic configuration")
Cc: [email protected]
Signed-off-by: Chengchang Tang <[email protected]>
Signed-off-by: Min Hu (Connor) <[email protected]>
show more ...
|