DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ori Kam <orika@nvidia.com>
To: David Marchand <david.marchand@redhat.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 09:31:39 +0000	[thread overview]
Message-ID: <MW2PR12MB466610C796B327126C923058D6499@MW2PR12MB4666.namprd12.prod.outlook.com> (raw)
In-Reply-To: <CAJFAV8y0h7jtnmN96_9A5kOjCh_jRAGXROkqzpJvsfsBGtHGhA@mail.gmail.com>



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

In those cases application will be slow even if he didn't offload the rules,
I assume we can say that if application wants to use this he should know
that other packets will have some performance issues.

From my point of view if application requested the tunnel offload it should
always check this function.

> 
> --
> David Marchand


  reply	other threads:[~2023-06-01  9:31 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 [this message]
2023-06-01  9:43         ` David Marchand
2023-06-01 10:02           ` Ori Kam
2023-06-01 10:03             ` David Marchand
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=MW2PR12MB466610C796B327126C923058D6499@MW2PR12MB4666.namprd12.prod.outlook.com \
    --to=orika@nvidia.com \
    --cc=aman.deep.singh@intel.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --cc=i.maximets@ovn.org \
    --cc=matan@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).