From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 39AA442D3F; Sun, 25 Jun 2023 03:32:29 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C1A6240EDC; Sun, 25 Jun 2023 03:32:28 +0200 (CEST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id 542F840A7F for ; Sun, 25 Jun 2023 03:32:25 +0200 (CEST) Received: from kwepemi500012.china.huawei.com (unknown [172.30.72.56]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4QpYKj5Z5rzMpRp; Sun, 25 Jun 2023 09:29:13 +0800 (CST) Received: from [10.78.231.32] (10.78.231.32) by kwepemi500012.china.huawei.com (7.221.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Sun, 25 Jun 2023 09:32:22 +0800 Message-ID: <71b7eeb1-45a8-978e-bb7b-fb24535de714@huawei.com> Date: Sun, 25 Jun 2023 09:32:22 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.0.3 Subject: Re: [PATCH v3 0/2] enhance bonding PMD to support the LACP negotiation To: Ferruh Yigit , Chaoyong He , Chas Williams CC: oss-drivers , Niklas Soderlund , "dev@dpdk.org" , Aman Singh , Thomas Monjalon References: <20230216083231.4721-1-chaoyong.he@corigine.com> <20230301024826.885727-1-chaoyong.he@corigine.com> <470f085b-d479-4ea8-abdb-0de483439d13@amd.com> <8cce799c-3c71-4aa3-e600-3f85dce14692@amd.com> From: "humin (Q)" In-Reply-To: <8cce799c-3c71-4aa3-e600-3f85dce14692@amd.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.78.231.32] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemi500012.china.huawei.com (7.221.188.12) X-CFilter-Loop: Reflected X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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. >