> On 6/6/2023 2:23 AM, Chaoyong He wrote: > > A gentle ping on this series. ... > >>> Long Wu (2): > >>> net/bonding: add independent LACP sending function > >>> app/testpmd: add support for bonding port's LACP negotiation > >>> > >>> app/test-pmd/config.c | 19 ++++++++ > >>> app/test-pmd/parameters.c | 4 ++ > >>> app/test-pmd/testpmd.c | 37 +++++++++++++++ > >>> app/test-pmd/testpmd.h | 4 ++ > >>> doc/guides/testpmd_app_ug/run_app.rst | 4 ++ > >>> drivers/net/bonding/rte_eth_bond_8023ad.c | 58 > >>> +++++++++++++++++++++++ > >> drivers/net/bonding/rte_eth_bond_8023ad.h > >>> | 21 ++++++++ > >>> drivers/net/bonding/version.map | 8 ++++ > >>> 8 files changed, 155 insertions(+) > >>> > >>> -- > >>> 2.39.1 > > > > Hi Chaoyong, > > Sorry for the delay, bonding maintainers are cc'ed. > > I can see this set adds new bonding specific APIs, instead can't application > (in > this case testpmd) call bonding Tx function explicitly to handle LACP packets?
Actually, I think apps should not aware of LACP packets because these packets are stored by bonding pmd(port->tx_ring). > Or should we have a special forwarding mode for bonding, as we have one for > ICMP echo? Yes, both ICMP and LACP are protocol. But LACP is related to a type of port (bonding port in mode4). Of course, we can add a special forwarding mode for bonding, but that will make it valid in very narrow situation. What I really want is to support mode4 bonding port on every forward mode of testpmd, and I also want to treat dpdk bonding port as a regular NIC.
