From: Ferruh Yigit <ferruh.yigit@amd.com>
To: Chaoyong He <chaoyong.he@corigine.com>,
Chas Williams <chas3@att.com>,
"Min Hu (Connor)" <humin29@huawei.com>
Cc: oss-drivers <oss-drivers@corigine.com>,
Niklas Soderlund <niklas.soderlund@corigine.com>,
"dev@dpdk.org" <dev@dpdk.org>,
Aman Singh <aman.deep.singh@intel.com>,
Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCH v3 0/2] enhance bonding PMD to support the LACP negotiation
Date: Fri, 23 Jun 2023 14:32:45 +0100 [thread overview]
Message-ID: <8cce799c-3c71-4aa3-e600-3f85dce14692@amd.com> (raw)
In-Reply-To: <SJ0PR13MB5545F83AC7A75E58915A33649E53A@SJ0PR13MB5545.namprd13.prod.outlook.com>
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?
next prev parent reply other threads:[~2023-06-23 13:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-16 7:15 [PATCH " Chaoyong He
2023-02-16 7:15 ` [PATCH 1/2] net/bonding: add independent LACP sending function Chaoyong He
2023-02-16 19:47 ` Stephen Hemminger
2023-02-20 9:46 ` Simon Horman
2023-02-20 16:31 ` Stephen Hemminger
2023-02-22 6:47 ` Chaoyong He
2023-02-16 7:15 ` [PATCH 2/2] app/testpmd: add support for bonding port's LACP negotiation Chaoyong He
2023-02-16 8:32 ` [PATCH v2 0/2] enhance bonding PMD to support the " Chaoyong He
2023-02-16 8:32 ` [PATCH v2 1/2] net/bonding: add independent LACP sending function Chaoyong He
2023-02-16 8:32 ` [PATCH v2 2/2] app/testpmd: add support for bonding port's LACP negotiation Chaoyong He
2023-02-16 17:05 ` Ferruh Yigit
2023-02-22 6:47 ` Chaoyong He
2023-03-01 2:48 ` [PATCH v3 0/2] enhance bonding PMD to support the " Chaoyong He
2023-03-01 2:48 ` [PATCH v3 1/2] net/bonding: add independent LACP sending function Chaoyong He
2023-03-01 2:48 ` [PATCH v3 2/2] app/testpmd: add support for bonding port's LACP negotiation Chaoyong He
2023-03-15 12:03 ` [PATCH v3 0/2] enhance bonding PMD to support the " Niklas Söderlund
2023-05-12 1:50 ` Chaoyong He
2023-06-06 1:23 ` Chaoyong He
2023-06-06 16:48 ` Ferruh Yigit
2023-06-07 3:10 ` Chaoyong He
2023-06-23 13:32 ` Ferruh Yigit [this message]
2023-06-25 1:32 ` humin (Q)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8cce799c-3c71-4aa3-e600-3f85dce14692@amd.com \
--to=ferruh.yigit@amd.com \
--cc=aman.deep.singh@intel.com \
--cc=chaoyong.he@corigine.com \
--cc=chas3@att.com \
--cc=dev@dpdk.org \
--cc=humin29@huawei.com \
--cc=niklas.soderlund@corigine.com \
--cc=oss-drivers@corigine.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).