[PATCH v3 0/2] enhance bonding PMD to support the LACP negotiation

[humin (Q)]

Hi, Ferruh,

在 2023/6/23 21:32, Ferruh Yigit 写道:
> On 6/7/2023 4:10 AM, Chaoyong He wrote:
>>> 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.
>>
> It makes sense to make bonding work as regular NIC and supported by all
> forwarding modes.
> But current patch adds bonding specific check to the shared forwarding
> function, that is not good I think.
>
> If application doesn't need to know about LACP packages, or if there is
> no decision making required by application, can we handle LACP packets
> within bonding PMD, transparent to application?
>
> Chas, Connor, what do you think?

Agree with you, Currently testpmd is too "big" to add specific check.

Also, private APIs should be restricted to add because we want to make

bonding device as a  regular NIC device.


>