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 55C3F459B4 for ; Tue, 17 Sep 2024 00:58:36 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C540F40261; Tue, 17 Sep 2024 00:58:35 +0200 (CEST) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by mails.dpdk.org (Postfix) with ESMTP id 434D44021F for ; Tue, 17 Sep 2024 00:58:34 +0200 (CEST) Received: by mail-lj1-f181.google.com with SMTP id 38308e7fff4ca-2f029e9c9cfso39477221fa.2 for ; Mon, 16 Sep 2024 15:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1726527513; x=1727132313; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QTac2RQQGD+fu4I1xlwVsb7VcdyKWBQ7NEdcaqgvXm4=; b=HI9lTUWO35l4UpTYnXyvWICia0j0oM5pjhLuRl+tZTzHGo137J7MZ69Ihr6fqtwUo8 5EuxAmhhErGrIIpF6lWMyYSLT09rhuQiuAD1cv8PEMWc7CM/R5x1wYaVj//JebK2Lyaj J9SjjXIhssNasrm5RyOAVy5YSSr+C2/JGChzs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726527513; x=1727132313; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QTac2RQQGD+fu4I1xlwVsb7VcdyKWBQ7NEdcaqgvXm4=; b=M9emJURMeOYYMZDRMHyH0ZkFFi7wp7vKqP8iwNQU93wuGsmi0EiwKntm+bIfzPknh2 30MN6N1EEw8p+6t9siSN9eI52P52YWp5DT7LgJJhrj0T78mOQpMkfA4VZX7m4oeyu6qA F/C2NF5w6XxwzPvEdqHOiwvh11ZqR9z7fdVltGgh/LunQylKk4m59WD2pbyK6bUvWJkx wDWNpXEBdmm3l/TusFhN9sen2MkDs8GXP6qcGUVNZRc3Ulsi2pFC1egRnhoFrvrZRbVU rsmXb4dkFg0KodTV0U+s0jxivxB4wAQ+h22ObOiq0iqj00GZmB29vEgE0D76+YMCRLTy 1OOg== X-Forwarded-Encrypted: i=1; AJvYcCWi0J9eUooUlmfkzbEFWCGVO8j4iAwX8Wb3kpCLeE+VdceD+okV1W9qOJW3V5M1l12MhNgttA==@dpdk.org X-Gm-Message-State: AOJu0Yzc6pBjAQkrJsbAYCtnPsQTrHxbSj1pyDkAYXJMlQtVBwLvXk7G delzTGdOGHOtFf73Cs4Qyq96n0Q5tx2d1RhXKKzHY3tSeoLxHoICUN02HU32eSL+8sVfwjt1l90 Fn5hfzmF1SXuLNEe7LBS/a7CZMEZFp/ia6CzsHKF4N1Tjk2Jq13RxP1r23HHihob8l6dAXOQVOK uqEbt4PsU= X-Google-Smtp-Source: AGHT+IH1Ky3EikWQbmgDV+ZhabHakP48Jmr3QIeHk5+Woi3UeJsVc4KBPKU02/MIuLVoojU+gQAVbPxivBwP3ShdFL4= X-Received: by 2002:a05:651c:b11:b0:2ef:2ba5:d214 with SMTP id 38308e7fff4ca-2f7918e4af7mr86240431fa.4.1726527513307; Mon, 16 Sep 2024 15:58:33 -0700 (PDT) MIME-Version: 1.0 References: <20240903170350.7e663864@hermes.local> <20240904154246.1c5bbb58@hermes.local> <20240912160948.3714f01d@hermes.local> In-Reply-To: From: Nandini Rangaswamy Date: Mon, 16 Sep 2024 15:58:21 -0700 Message-ID: Subject: Re: Netvsc vs Failsafe Performance To: Long Li Cc: Stephen Hemminger , "users@dpdk.org" Content-Type: multipart/alternative; boundary="0000000000002053460622448388" X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --0000000000002053460622448388 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Long, I tested this patch and it works as expected. The UDP IPv6 RSS offload bit is set and my dpdk app is able to successfully configure the netvsc port. Regards, Nandini On Fri, Sep 13, 2024 at 2:29=E2=80=AFPM Nandini Rangaswamy < nandini.rangaswamy@broadcom.com> wrote: > Thanks Long Li. > I shall try this patch and get back to you. > > On Fri, Sep 13, 2024 at 2:27=E2=80=AFPM Long Li wr= ote: > >> It=E2=80=99s a bug in netvsc for not reporting RTE_ETH_RSS_NONFRAG_IPV6_= UDP. It >> is implied as in the case in IPV4. >> >> >> >> Can you try the following patch? >> >> >> >> diff --git a/drivers/net/netvsc/hn_rndis.c b/drivers/net/netvsc/hn_rndis= .c >> >> index 1ba75ee804..fe1f04d8d9 100644 >> >> --- a/drivers/net/netvsc/hn_rndis.c >> >> +++ b/drivers/net/netvsc/hn_rndis.c >> >> @@ -717,6 +717,7 @@ hn_rndis_query_rsscaps(struct hn_data *hv, >> >> if (caps.ndis_caps & NDIS_RSS_CAP_IPV6) >> >> hv->rss_offloads |=3D RTE_ETH_RSS_IPV6 >> >> | RTE_ETH_RSS_NONFRAG_IPV6_TCP; >> >> + | RTE_ETH_RSS_NONFRAG_IPV6_UDP; >> >> if (caps.ndis_caps & NDIS_RSS_CAP_IPV6_EX) >> >> hv->rss_offloads |=3D RTE_ETH_RSS_IPV6_EX >> >> | RTE_ETH_RSS_IPV6_TCP_EX; >> >> >> >> >> >> *From:* Nandini Rangaswamy >> *Sent:* Friday, September 13, 2024 10:56 AM >> *To:* Stephen Hemminger >> *Cc:* Long Li ; users@dpdk.org >> *Subject:* Re: Netvsc vs Failsafe Performance >> >> >> >> Thanks for clarifying the question regarding Txd size Stephen. >> >> I tested out the RSS for TCP UDP. >> >> As suggested , I set the TCP flags alone in RSS conf and configured the >> netvsc port. >> >> >> >> struct rte_eth_conf conf =3D { >> >> .intr_conf =3D { >> >> .lsc =3D !dpdk.lsc_intr_disable && !dpdk_if->lsc_intr_disable && >> >> !!(dev->data->dev_flags & RTE_ETH_DEV_INTR_LSC), >> >> }, >> >> .rxmode =3D { >> >> .mq_mode =3D RTE_ETH_MQ_RX_RSS, >> >> .offloads =3D RTE_ETH_RX_OFFLOAD_VLAN_STRIP | >> RTE_ETH_RX_OFFLOAD_IPV4_CKSUM | >> >> RTE_ETH_RX_OFFLOAD_RSS_HASH | RTE_ETH_RX_OFFLOAD_UDP_CKSUM, >> >> }, >> >> .rx_adv_conf.rss_conf =3D { >> >> .rss_hf =3D RTE_ETH_RSS_NONFRAG_IPV4_TCP | RTE_ETH_RSS_NONFRAG_IPV6_TCP, >> >> .rss_key =3D conf_rss_key, >> >> .rss_key_len =3D rss_key_len, >> >> }, >> >> .txmode =3D { >> >> .offloads =3D RTE_ETH_TX_OFFLOAD_UDP_CKSUM | RTE_ETH_TX_OFFLOAD_IPV4_CKS= UM, >> >> }, >> >> }; >> >> *rte_eth_dev_configure*(, num_rxq,num_txq, &conf); >> >> uint8_t rss_key_temp[64]; >> >> struct rte_eth_rss_conf rss_conf =3D { >> >> .rss_key =3D rss_key_temp, >> >> .rss_key_len =3D sizeof(rss_key_temp), >> >> }; >> >> ret =3D *rte_eth_dev_rss_hash_conf_get*(, &rss_conf); >> >> >> >> >> >> Now the VF port RSS offloads show only TCP flags set and not UDP. I >> assumed that even the UDP flags might be set. Is this expected ? >> >> >> >> Regards, >> >> Nandini >> >> >> >> >> >> On Thu, Sep 12, 2024 at 4:09=E2=80=AFPM Stephen Hemminger < >> stephen@networkplumber.org> wrote: >> >> On Thu, 12 Sep 2024 13:47:37 -0700 >> Nandini Rangaswamy wrote: >> >> > Thanks for your response Long Li. >> > I see with netvsc the maximum number of Tx descriptors is restricted t= o >> > 4096 whereas the number of Rx descriptors is restricted to 8192. >> > But, for failsafe PMD , we see that both the number of Txd and Rxd is >> > restricted to 8192. >> > How is netvsc PMD giving the same performance as failsafe PMD ? >> > >> > Regards >> >> I think the limits there were somewhat arbitrary chose with netvsc. >> Don't remember a hard reason that would block larger sizes. >> >> >> Having really big rings won't help performance (i.e BufferBloat) and >> could a lot of memory consumption. When all heavy data traffic goes >> through >> the VF and that ring is different. Only DoS attacks should be impacted >> by rx/tx descriptor limits in the netvsc device. The linux driver actual= ly >> has much smaller buffer. >> >> >> This electronic communication and the information and any files >> transmitted with it, or attached to it, are confidential and are intende= d >> solely for the use of the individual or entity to whom it is addressed a= nd >> may contain information that is confidential, legally privileged, protec= ted >> by privacy laws, or otherwise restricted from disclosure to anyone else.= If >> you are not the intended recipient or the person responsible for deliver= ing >> the e-mail to the intended recipient, you are hereby notified that any u= se, >> copying, distributing, dissemination, forwarding, printing, or copying o= f >> this e-mail is strictly prohibited. If you received this e-mail in error= , >> please return the e-mail to the sender, delete it from your computer, an= d >> destroy any printed copy of it. >> > --=20 This electronic communication and the information and any files transmitted= =20 with it, or attached to it, are confidential and are intended solely for=20 the use of the individual or entity to whom it is addressed and may contain= =20 information that is confidential, legally privileged, protected by privacy= =20 laws, or otherwise restricted from disclosure to anyone else. If you are=20 not the intended recipient or the person responsible for delivering the=20 e-mail to the intended recipient, you are hereby notified that any use,=20 copying, distributing, dissemination, forwarding, printing, or copying of= =20 this e-mail is strictly prohibited. If you received this e-mail in error,= =20 please return the e-mail to the sender, delete it from your computer, and= =20 destroy any printed copy of it. --0000000000002053460622448388 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Long,
I tested this patch and it works as expe= cted. The UDP IPv6 RSS offload bit is set and my dpdk app is able to succes= sfully configure the netvsc port.
Regards,
Nandini

On Fri, Sep 13, 2024 at 2:29=E2=80=AFPM Nandini Rangaswamy <nandini.rangaswamy@broadcom.com= > wrote:
Thanks Long Li.
I shall try this patch and get back to you= .

On Fri, Sep 13, 2024 at 2:27=E2=80=AFPM Long Li <longli@microsoft.com> wrot= e:

It=E2=80=99s a bug in= netvsc for not reporting RTE_ETH_RSS_NONFRAG_IPV6_UDP. It is implied as in= the case in IPV4.

=C2=A0<= /span>

Can you try the follo= wing patch?

=C2=A0<= /span>

diff --git a/drivers/= net/netvsc/hn_rndis.c b/drivers/net/netvsc/hn_rndis.c<= /p>

index 1ba75ee804..fe1= f04d8d9 100644

--- a/drivers/net/net= vsc/hn_rndis.c

+++ b/drivers/net/net= vsc/hn_rndis.c

@@ -717,6 +717,7 @@ h= n_rndis_query_rsscaps(struct hn_data *hv,

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 if (caps.ndis_caps & NDIS_RSS_CAP_IPV6)=

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 hv-&g= t;rss_offloads |=3D RTE_ETH_RSS_IPV6

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | RTE_ETH_RSS_NONFRAG_IPV6_TCP;<= u>

+=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | RTE_ETH_RSS_NONFRAG_IPV6_UDP;<= /u>

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 if (caps.ndis_caps & NDIS_RSS_CAP_IPV6_EX)=

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 hv-&g= t;rss_offloads |=3D RTE_ETH_RSS_IPV6_EX

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | RTE_ETH_RSS_IPV6_TCP_EX;

=C2=A0<= /span>

=C2=A0<= /span>

From: Nandini Rangaswamy <nandini.rangaswamy@broadcom.com>
Sent: Friday, September 13, 2024 10:56 AM
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Long Li <longli@microsoft.com>; users@dpdk.org
Subject: Re: Netvsc vs Failsafe Performance

=C2=A0

Thanks for clarifying the question=C2=A0regarding Tx= d size Stephen.

I tested out the RSS for TCP UDP.

As suggested , I set the TCP flags alone in RSS conf= and configured the netvsc port.

=C2=A0

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(1= 22,62,157)">struct rte_eth_conf conf =3D {

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(5= 1,51,51)">.intr_conf =3D {

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(5= 1,51,51)">.lsc =3D !dpdk.= lsc_intr_disable && !dpdk_if->= lsc_intr_disable &&

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(1= 19,119,119)">!!(dev->data->dev_flags & RTE_ETH_DEV_INTR_LSC),

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(1= 19,119,119)">},

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(5= 1,51,51)">.rxmode =3D {

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(5= 1,51,51)">.mq_mode =3D RTE_ETH_MQ_RX_RSS,

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(5= 1,51,51)">.offloads =3D RTE_ETH_RX_OFFLOAD_VLAN_STRIP | RTE_ETH_RX_OFFLOAD_IPV4_CKSUM |

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(5= 1,51,51)">RTE_ETH_RX_OFFLOAD_RSS_HASH | RTE_ETH_RX_OFFLOAD_UDP_CKSUM,

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(1= 19,119,119)">},

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(5= 1,51,51)">.rx_adv_conf.rss_conf =3D {

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(5= 1,51,51)">.rss_hf =3D RTE_ETH_RSS_NONFRAG_IPV4_TCP | RTE_ETH_RSS_NONFRAG_IPV6_TCP,

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(5= 1,51,51)">.rss_key =3D conf_rss_key,

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(5= 1,51,51)">.rss_key_len =3D rss_key_len= ,

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(1= 19,119,119)">},

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(5= 1,51,51)">.txmode =3D {

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(5= 1,51,51)">.offloads =3D RTE_ETH_TX_OFFLOAD_UDP_CKSUM | RTE_ETH_TX_OFFLOAD_IPV4_CKSUM,

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(1= 19,119,119)">},

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(1= 19,119,119)">};

<= b>rte_eth_dev_configure(<netvsc port>, num_rxq,num_tx= q, &conf);

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(1= 22,62,157)">uint8_t rss_key_temp[64= ];

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(1= 22,62,157)">struct rte_eth_rss_conf rss_conf =3D {

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(5= 1,51,51)">.rss_key =3D rss_key_temp,

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(5= 1,51,51)">.rss_key_len =3D sizeof(rss_key_temp),

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(1= 19,119,119)">};

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(5= 1,51,51)">ret =3D rte_eth_dev_rss_hash_conf_get(<VF port>, &rss_conf);=

<= span style=3D"font-size:9pt;font-family:"Courier New";color:rgb(5= 1,51,51)">=C2=A0

=C2=A0

Now the VF port RSS offloads show only TCP flags set= and not UDP. I assumed that even the UDP flags might be set. Is this expec= ted ?

=C2=A0

Regards,

Nandini=C2=A0

=C2=A0

=C2=A0

On Thu, Sep 12, 2024 at 4:09=E2=80=AFPM Stephen Hemminger <stephen@networkplumber.o= rg> wrote:

On Thu, 12 Sep 2024 13:47:37 -0700
Nandini Rangaswamy <nandini.rangaswamy@broadcom.com> wrote:

> Thanks for your response Long Li.
> I see with netvsc the maximum number of Tx descriptors is restricted t= o
> 4096 whereas the number of Rx descriptors is restricted to 8192.
> But, for failsafe PMD , we see that both the number of Txd and Rxd is<= br> > restricted to 8192.
> How is netvsc PMD giving the same performance as failsafe PMD ?
>
> Regards

I think the limits there were somewhat arbitrary chose with netvsc.
Don't remember a hard reason that would block larger sizes.


Having really big rings won't help performance (i.e BufferBloat) and could a lot of memory consumption. When all heavy data traffic goes through=
the VF and that ring is different. Only DoS attacks should be impacted
by rx/tx descriptor limits in the netvsc device. The linux driver actually<= br> has much smaller buffer.


This electronic= communication and the information and any files transmitted with it, or at= tached to it, are confidential and are intended solely for the use of the i= ndividual or entity to whom it is addressed and may contain information that is confidential, legally privil= eged, protected by privacy laws, or otherwise restricted from disclosure to= anyone else. If you are not the intended recipient or the person responsib= le for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, dis= tributing, dissemination, forwarding, printing, or copying of this e-mail i= s strictly prohibited. If you received this e-mail in error, please return = the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.


This ele= ctronic communication and the information and any files transmitted with it= , or attached to it, are confidential and are intended solely for the use o= f the individual or entity to whom it is addressed and may contain informat= ion that is confidential, legally privileged, protected by privacy laws, or= otherwise restricted from disclosure to anyone else. If you are not the in= tended recipient or the person responsible for delivering the e-mail to the= intended recipient, you are hereby notified that any use, copying, distrib= uting, dissemination, forwarding, printing, or copying of this e-mail is st= rictly prohibited. If you received this e-mail in error, please return the = e-mail to the sender, delete it from your computer, and destroy any printed= copy of it. --0000000000002053460622448388--