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 BC8F545B61 for ; Thu, 17 Oct 2024 20:32:16 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 827D44029C; Thu, 17 Oct 2024 20:32:16 +0200 (CEST) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by mails.dpdk.org (Postfix) with ESMTP id EEB2B4025F for ; Thu, 17 Oct 2024 20:32:14 +0200 (CEST) Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-2fb56cb61baso10887741fa.1 for ; Thu, 17 Oct 2024 11:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1729189934; x=1729794734; 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=UjScxvwRRaJ0IoTu/0Aod8rQFVELNmdDmV9tCWMzCO0=; b=bxakSf+tTH43RbOSWulL0dfhmHbgcy+MFahYWkmf7T5KdPlsk6/sC/CBI1qMItBaFN 3VubFm4Dca/xa8VSORYBE4T7be67N+BXoUkZnMIWsm7ZZ0+DD10JU1cr27LSdrnDlQ/I B25YFTnLNmw2lg//LoIqGaPQkG4e9dxN6MTEo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729189934; x=1729794734; 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=UjScxvwRRaJ0IoTu/0Aod8rQFVELNmdDmV9tCWMzCO0=; b=EfTJBE42wbAEmBI/TWJrj+PL6IAPIQT/HUug97O3Ql+jdFar1+VljlcxV9ivf05rcF sRfQMMf+L3SpS449UwPN0gqEDGU7S8s047Ci5nXE+Kqo3VlE3phuFm7PVUeWQ0a5GEMm oRCcq0gtEksONJGHPAJJyWPrE4GILt1LNpvAdqAqMA9uHi294ttWaVVx0pvb6ghOBbeA WAZzXNnZG1Q7GXD0m0cfjlBC6SSV0FFGtgBsX7L87sY4fRO6LPY1x2qpwMobNkzU72Nx w2FpiXVeoebRDAAttIIwvtKuxe9LtesxsfP1NywT28sxFydxdOt4oEzUFKjEd4CBK7Am 2ILg== X-Forwarded-Encrypted: i=1; AJvYcCW4ORuv1SNoGZuE0kbOMTqSWPKVylbKa267sI3tmiJFT501gkdxM1he/VlFVHwrhblaaoLlFA==@dpdk.org X-Gm-Message-State: AOJu0YyuCWv17DTIrLl6c13AMs93wbG5XMPxCsEMIdA4P+Jn53PxcRv6 sz9GOqniMGARk11q+OTzwBsgYff1wdCoUctHJi4u96CIq0dZ7pcMLdwPi4G5ZBOHNqd3N4hq4V9 cf9/0NQT0OAxcmvVD8cX1Rr+oQuQjym76ZtMe+e+aQ6QrE1OPm5h1g24rJH66cibfK+WFP9Kn9h Jd1S2u2zvhIzJb/rr37Q== X-Google-Smtp-Source: AGHT+IEzv0/dDtw0Z03Br5/msefdQkS1gtCWB631eCAuljVfjxOa34RV+IhESUSTbNCQhDhFvU0MqQ4BNJcjxnOpxdM= X-Received: by 2002:a2e:bc1a:0:b0:2fb:5688:55c0 with SMTP id 38308e7fff4ca-2fb5688591emr85306641fa.38.1729189934180; Thu, 17 Oct 2024 11:32:14 -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: Thu, 17 Oct 2024 11:32:02 -0700 Message-ID: Subject: Re: Netvsc vs Failsafe Performance To: Long Li Cc: Stephen Hemminger , "users@dpdk.org" Content-Type: multipart/alternative; boundary="000000000000c6d3e40624b06798" 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 --000000000000c6d3e40624b06798 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Long, I could not get to this in the past month. I have resumed netvsc work today. I shall get back to you as soon as possible. Regards, Nandini On Wed, Oct 16, 2024 at 12:26=E2=80=AFPM Long Li wro= te: > Hi Nandini, > > > > Do you have any luck with UDP traffic? > > > > Thanks, > > Long > > > > *From:* Nandini Rangaswamy > *Sent:* Thursday, September 19, 2024 9:46 AM > *To:* Long Li > *Cc:* Stephen Hemminger ; users@dpdk.org > *Subject:* Re: Netvsc vs Failsafe Performance > > > > Hi Long Li, > > I shall test with UDP traffic and get back to you. > > Regards, > > Nandini > > > > On Tue, Sep 17, 2024 at 2:57=E2=80=AFPM Long Li wr= ote: > > Thank you! > > > > Are you seeing problems with UDP traffic on the receive side? If > everything works fine for you, I=E2=80=99m sending a patch. > > > > Long > > > > *From:* Nandini Rangaswamy > *Sent:* Monday, September 16, 2024 3:58 PM > *To:* Long Li > *Cc:* Stephen Hemminger ; users@dpdk.org > *Subject:* Re: Netvsc vs Failsafe Performance > > > > Hi Long, > > I tested this patch and it works as expected. The UDP IPv6 RSS offload bi= t > 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_U= DP. 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_CKS= UM > | > > 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_CKSU= M, > > }, > > }; > > *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 to > > 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 throu= gh > 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 actuall= y > has much smaller buffer. > > > This electronic communication and the information and any files > transmitted with it, or attached to it, are confidential and are intended > solely for the use of the individual or entity to whom it is addressed an= d > may contain information that is confidential, legally privileged, protect= ed > by privacy laws, or otherwise restricted from disclosure to anyone else. = If > you are not the intended recipient or the person responsible for deliveri= ng > the e-mail to the intended recipient, you are hereby notified that any us= e, > copying, distributing, dissemination, forwarding, printing, or copying of > 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, and > destroy any printed copy of it. > > > This electronic communication and the information and any files > transmitted with it, or attached to it, are confidential and are intended > solely for the use of the individual or entity to whom it is addressed an= d > may contain information that is confidential, legally privileged, protect= ed > by privacy laws, or otherwise restricted from disclosure to anyone else. = If > you are not the intended recipient or the person responsible for deliveri= ng > the e-mail to the intended recipient, you are hereby notified that any us= e, > copying, distributing, dissemination, forwarding, printing, or copying of > 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, and > destroy any printed copy of it. > > > This electronic communication and the information and any files > transmitted with it, or attached to it, are confidential and are intended > solely for the use of the individual or entity to whom it is addressed an= d > may contain information that is confidential, legally privileged, protect= ed > by privacy laws, or otherwise restricted from disclosure to anyone else. = If > you are not the intended recipient or the person responsible for deliveri= ng > the e-mail to the intended recipient, you are hereby notified that any us= e, > copying, distributing, dissemination, forwarding, printing, or copying of > 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, and > 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. --000000000000c6d3e40624b06798 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Long,
I could not get to this in the past mont= h. I have resumed netvsc work today. I shall get back to you as soon as pos= sible.
Regards,
Nandini

On Wed, Oct 16, 2024 at 12= :26=E2=80=AFPM Long Li <longli@m= icrosoft.com> wrote:

Hi Nandini,

=C2=A0

Do you have any luck with UDP traffic?=

=C2=A0

Thanks,

Long

=C2=A0

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

=C2=A0

Hi Long Li,

I shall test with UDP traffic and get=C2=A0back to y= ou.

Regards,

Nandini

=C2=A0

On Tue, Sep 17, 2024 at 2:57=E2=80=AFPM Long Li <longli@microsoft.com> wrote:

Thank you!

=C2=A0

Are you seeing problems with UDP traffic on the rece= ive side? If everything works fine for you, I=E2=80=99m sending a patch.=

=C2=A0

Long

=C2=A0

From: Nandini Rangaswamy <nandini.rangaswamy@broadcom.com>
Sent: Monday, September 16, 2024 3:58 PM
To: Long Li <longli@microsoft.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>; users@dpdk.org
Subject: Re: Netvsc vs Failsafe Performance

=C2=A0

Hi=C2=A0Long,

I tested this patch and it works as expected. The UD= P IPv6 RSS offload bit is set and my dpdk app is able to successfully confi= gure the netvsc port.

Regards,

Nandini

=C2=A0

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.

=C2=A0

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

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<= u>

Can you try the follo= wing patch?

=C2=A0<= u>

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;<= /span>

+=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;

=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<= u>

=C2=A0<= u>

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

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_CKSUM,

},

};

rte_eth_dev_configure(<netvsc port>, num_rxq,num_tx= q, &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(<VF port>, &rss_conf);=

=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 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 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. --000000000000c6d3e40624b06798--