DPDK patches and discussions
 help / color / mirror / Atom feed
From: David Marchand <david.marchand@redhat.com>
To: Ori Kam <orika@nvidia.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	 "NBU-Contact-Thomas Monjalon (EXTERNAL)" <thomas@monjalon.net>,
	"i.maximets@ovn.org" <i.maximets@ovn.org>,
	 Aman Singh <aman.deep.singh@intel.com>,
	Yuying Zhang <yuying.zhang@intel.com>,
	 Matan Azrad <matan@nvidia.com>,
	Slava Ovsiienko <viacheslavo@nvidia.com>,
	 Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
	Ferruh Yigit <ferruh.yigit@amd.com>
Subject: Re: [RFC PATCH] ethdev: advertise flow restore in mbuf
Date: Thu, 1 Jun 2023 12:03:57 +0200	[thread overview]
Message-ID: <CAJFAV8yRtPN8gGZaNG8QqH=3FbB5ho0iDMu7aRJ4yRcQrf0gJg@mail.gmail.com> (raw)
In-Reply-To: <MW2PR12MB466656A2B3AA716D388FF494D6499@MW2PR12MB4666.namprd12.prod.outlook.com>

On Thu, Jun 1, 2023 at 12:02 PM Ori Kam <orika@nvidia.com> wrote:
>
> Hi David,
>
> > -----Original Message-----
> > From: David Marchand <david.marchand@redhat.com>
> > Sent: Thursday, June 1, 2023 12:43 PM
> > Subject: Re: [RFC PATCH] ethdev: advertise flow restore in mbuf
> >
> > On Thu, Jun 1, 2023 at 11:31 AM Ori Kam <orika@nvidia.com> wrote:
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: David Marchand <david.marchand@redhat.com>
> > > > Sent: Thursday, June 1, 2023 11:48 AM
> > > >
> > > > On Wed, May 24, 2023 at 8:44 PM David Marchand
> > > > <david.marchand@redhat.com> wrote:
> > > > > On Wed, May 24, 2023 at 6:00 PM Ori Kam <orika@nvidia.com> wrote:
> > > > > > > As reported by Ilya [1], unconditionally calling
> > > > > > > rte_flow_get_restore_info() impacts an application performance for
> > > > drivers
> > > > > > > that do not provide this ops.
> > > > > > > It could also impact processing of packets that require no call to
> > > > > > > rte_flow_get_restore_info() at all.
> > > > > > >
> > > > > > > Advertise in mbuf (via a dynamic flag) whether the driver has more
> > > > > > > metadata to provide via rte_flow_get_restore_info().
> > > > > > > The application can then call it only when required.
> > > > > > >
> > > > > > > Link: http://inbox.dpdk.org/dev/5248c2ca-f2a6-3fb0-38b8-
> > > > > > > 7f659bfa40de@ovn.org/
> > > > > > > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > > > > > > ---
> > > > > > > Note: I did not test this RFC patch yet but I hope we can resume
> > and
> > > > > > > maybe conclude on the discussion for the tunnel offloading API.
> > > > > > >
> > > > > >
> > > > > > I think your approach has a good base but what happens if
> > > > > > it is not relevant for all flows? In this case your solution will not work.
> > > > >
> > > > > Sorry, I am not following.
> > > > > Could you develop?
> > > >
> > > > I still don't get your comment, could you give an example/usecase
> > > > where this approach can't work?
> > > > Thanks.
> > > >
> > > I'm think of a use case that some flows have the restore info, while
> > > other don't for example, we get arp packets or some packets that
> > > are not tunneled, and we also get tunneled packets.
> > >
> > > Or for example PMD supports this flag but the application didn't offload
> > such a rule yet.
> >
> > Again, maybe I missed something, but my proposal is for a *per packet*
> > report from the driver.
> > I am not for a global driver capability, if this is what you have in mind.
> >
> My bad, per packet solves the issue I was talking about, but it makes it worse.
> This means that PMD needs to add logic in it's datapath. This may affect all
> traffic.

Well, look at the patch then, I already updated the driver.
I don't expect much of an impact with the current code though.


-- 
David Marchand


  reply	other threads:[~2023-06-01 10:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-05 10:31 David Marchand
2023-05-24 12:57 ` David Marchand
2023-05-24 16:00 ` Ori Kam
2023-05-24 18:44   ` David Marchand
2023-06-01  8:48     ` David Marchand
2023-06-01  9:31       ` Ori Kam
2023-06-01  9:43         ` David Marchand
2023-06-01 10:02           ` Ori Kam
2023-06-01 10:03             ` David Marchand [this message]
2023-06-14 16:46 ` Slava Ovsiienko
2023-06-15  8:00   ` David Marchand
2023-06-15 13:47 ` [RFC PATCH v2] " David Marchand
2023-06-19 12:20   ` Andrew Rybchenko
2023-06-19 13:57   ` Slava Ovsiienko
2023-06-20 10:04   ` Ali Alnubani
2023-06-20 11:10 ` [RFC PATCH v3] " David Marchand
2023-06-20 16:43   ` Slava Ovsiienko
2023-06-21  7:43     ` David Marchand
2023-06-21 12:53     ` Ori Kam
2023-06-21  7:47   ` Ali Alnubani
2023-06-21 14:43 ` [PATCH v4] " David Marchand
2023-06-21 18:52   ` Ferruh Yigit
2023-07-31 20:41   ` Ilya Maximets
2023-09-26  9:17     ` David Marchand
2023-09-26 19:49       ` Ilya Maximets

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='CAJFAV8yRtPN8gGZaNG8QqH=3FbB5ho0iDMu7aRJ4yRcQrf0gJg@mail.gmail.com' \
    --to=david.marchand@redhat.com \
    --cc=aman.deep.singh@intel.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --cc=i.maximets@ovn.org \
    --cc=matan@nvidia.com \
    --cc=orika@nvidia.com \
    --cc=thomas@monjalon.net \
    --cc=viacheslavo@nvidia.com \
    --cc=yuying.zhang@intel.com \
    /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).