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 84BAA45BC8 for ; Thu, 24 Oct 2024 23:39:07 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4A22B40657; Thu, 24 Oct 2024 23:39:07 +0200 (CEST) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by mails.dpdk.org (Postfix) with ESMTP id 59438400EF for ; Thu, 24 Oct 2024 23:39:05 +0200 (CEST) Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2fb5be4381dso16060451fa.2 for ; Thu, 24 Oct 2024 14:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1729805945; x=1730410745; 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=EUAZjH7gn5rOVkJfe6uqniuDE6LDThz4IolkorbdceY=; b=gqp90D6nm8xlLfe8PxnCO0VO3Lgd9jK1x8afPCLmKKOYqRvW8FZOThqtAeLPkVpgB9 D+TidSrQYVfz41bX4EdE3exHMpfWFgfmgjOqVla5h99MpU5d1D6so3Ve7LJ/6j+Druqr BrPX2946es+mDVKkXpuPEIq3x+3PvxQVZJOCg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729805945; x=1730410745; 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=EUAZjH7gn5rOVkJfe6uqniuDE6LDThz4IolkorbdceY=; b=Bl9EaOCyvngYijzVYw90xx0HTb+jfW3nqd6hSXBBQRvyrMvPmlGKZjVSIWuwkuhQ9V Lsp2zx12dva8dX6GGASz+gUyJIE1OsLpIlKY0JM/JKpLstY8zN1M+FHayGC/XvgeRyoe K+nocB+Qid2EjgHEwT+b3RBWIr2jnwiuh/xpBgqe9j5FWBA6355FUR+C9ouMrGV8YS3l qNOUCAveAGMNSnx/u/UZrSBtVbu+uLeSFxje7PGy/oSkx7NzgJqfBDXgR/z/aBc8upYT 3w15o141J/FI1EPAj24gzVDQiMVWD7EX6i2lhTO4680i4VBMN24Tra5ZpsVxWP1y5nsY JeKA== X-Forwarded-Encrypted: i=1; AJvYcCV273sg48WBeHznoCA4PnJZbiydYkGW8qjZvXD5W0RiFfp49hcnjthxwSTwGMYT4IZHxBplBw==@dpdk.org X-Gm-Message-State: AOJu0YxiRRND4J96e+QUx+QNCrEaj/ch7skdnDT97+toiH0x2CBJeSJD Jjzefxc5aY2fpLqtrB8mbVEtu1Egn1BwoqRwQa88DXzQ9bPDvNfqha97Y8gA9xrp1DQ9uNM5i7Q oKhPo4VSBvgM8lQ+/MimhOl249GrqN49Zd5X6C7ePMgtN7rf+6QEXTiolKfElEaoZeRNCOXuI/0 23NuWFXJDhHN8D6GYZqA== X-Google-Smtp-Source: AGHT+IE7mNOa7AADmlfXL7wArm1eH7X0/uaIu8aH1R7F05zMHW9CQ4AVX9rkWJ9W9G57nJLR3WCIK0jPbGHnR+QHSKw= X-Received: by 2002:a2e:bc21:0:b0:2fa:bf53:1dad with SMTP id 38308e7fff4ca-2fca825b904mr21938001fa.31.1729805944612; Thu, 24 Oct 2024 14:39:04 -0700 (PDT) MIME-Version: 1.0 References: <20240919114719.2389589a@hermes.local> <20241024093357.2473c767@hermes.local> In-Reply-To: <20241024093357.2473c767@hermes.local> From: Nandini Rangaswamy Date: Thu, 24 Oct 2024 14:38:53 -0700 Message-ID: Subject: Re: Netvsc PMD : Hotplug handling : checksum offloads To: Stephen Hemminger Cc: Long Li , users@dpdk.org Content-Type: multipart/alternative; boundary="000000000000dc1a1506253fd430" 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 --000000000000dc1a1506253fd430 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Stephen/Long, I did some more code instrumentation and I observed that when a hotplug add event is received, the conf is applied back to VF and offloads work as expected. I also observe that when VF is removed, the offloads still continue to work as expected. Is this because the offloads are not unset when VF is removed = ? Regards, Nandini On Thu, Oct 24, 2024 at 9:33=E2=80=AFAM Stephen Hemminger < stephen@networkplumber.org> wrote: > On Wed, 23 Oct 2024 13:34:53 -0700 > Nandini Rangaswamy wrote: > > > Hi Stephen, > > The code looking at checksum flags in each packet would not give us > desired > > performance. Instead, should the dpdk app register callbacks for hotplu= g > > add and re-configure the checksum offloads when VF is added again? > > Regards, > > Nandini > > The code in hn_vf_add which is where netvsc PMD handles hot add of VF > should be feeding the current offload settings to the VF. > > Maybe the rte_eth_conf being passed to VF is incorrect, or > the configuration step there is failing. Probably need more instrumentati= on > and logs to tell. > --=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. --000000000000dc1a1506253fd430 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Stephen/Long,
I did some more code instrumentation = and I observed that when a hotplug add=C2=A0event is received, the conf is = applied back to VF and offloads work as expected.
I also observe = that when VF is removed, the offloads still continue to work as expected. I= s this because the offloads are not unset when VF is removed ?
Re= gards,
Nandini

On Thu, Oct 24, 2024 at 9:33=E2=80=AFAM Steph= en Hemminger <stephen@netw= orkplumber.org> wrote:
On Wed, 23 Oct 2024 13:34:53 -0700
Nandini Rangaswamy <nandini.rangaswamy@broadcom.com> wrote:

> Hi Stephen,
> The code looking at checksum flags in each packet would not give us de= sired
> performance. Instead, should the dpdk app register callbacks for hotpl= ug
> add and re-configure the checksum offloads when VF is added again?
> Regards,
> Nandini

The code in hn_vf_add which is where netvsc PMD handles hot add of VF
should be feeding the current offload settings to the VF.

Maybe the rte_eth_conf being passed to VF is incorrect, or
the configuration step there is failing. Probably need more instrumentation=
and logs to tell.

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. --000000000000dc1a1506253fd430--