DPDK patches and discussions
 help / color / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Andrew Rybchenko <arybchenko@solarflare.com>
Cc: dev@dpdk.org, Ori Kam <orika@mellanox.com>,
	"pbhagavatula@marvell.com" <pbhagavatula@marvell.com>,
	"ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
	"jerinj@marvell.com" <jerinj@marvell.com>,
	John McNamara <john.mcnamara@intel.com>,
	Marko Kovacevic <marko.kovacevic@intel.com>,
	Adrien Mazarguil <adrien.mazarguil@6wind.com>,
	david.marchand@redhat.com, ktraynor@redhat.com
Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: add flow action type update as an offload
Date: Thu, 31 Oct 2019 15:49:43 +0100
Message-ID: <3078181.9TjvbByyqQ@xps> (raw)
In-Reply-To: <a1a892a8-c83b-7c92-2d61-49d681e37383@solarflare.com>

31/10/2019 10:49, Andrew Rybchenko:
> On 10/28/19 5:00 PM, Ori Kam wrote:
> >> -----Original Message-----
> > From: Andrew Rybchenko <arybchenko@solarflare.com>
> >> On 10/28/19 1:50 PM, Ori Kam wrote:
> >>> Hi Pavan,
> >>>
> >>> Sorry for jumping in late.
> >>>
> >>> I don't understand why we need this feature. If the user didn't set any flow
> >> with MARK
> >>> then the user doesn't need to check it.
> >> There is pretty long discussion on the topic already, please, read [1].
> >>
> >> [1]
> >> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Finbox.dpdk
> >> .org%2Fdev%2F3251fc00-7598-1c4f-fc2a-
> >> 380065f0a435%40solarflare.com%2F&amp;data=02%7C01%7Corika%40mellan
> >> ox.com%7Ce3f779d4b7c44b682d6508d75b9d8688%7Ca652971c7d2e4d9ba6a4
> >> d149256f461b%7C0%7C0%7C637078604439019114&amp;sdata=sYooc%2FQ3C
> >> kUZG3gRFPlZrm8xMfMB9gOWWex5YIkWhMc%3D&amp;reserved=0
> >>
> > Thanks for the link, it was an interesting reading.
> >
> >>> Also it breaks compatibility.
> >> Yes, there is a deprecation notice for it.
> >>
> >>> If my understanding is correct the MARK field is going to be moved to
> >> dynamic field, and this
> >>> will be way to control the use of MARK.
> >> Yes and I think the offload should used to request dynamic
> >> field register. Similar to timestamp in dynamic mbuf examples.
> >> Application requests Rx timestamp offload, PMD registers dynamic
> >> filed.
> >>
> > In general it was decided that there will be no capability for rte_flow API, due to the fact that
> > it is impossible to support all possible combinations. For example a PMD can allow mark on Rx
> > while not supporting it on e-switch (transfer) or on Tx.
> > The only way to validate it is validating a flow. If the flow is validated then the action is supported.
> > This is the exact approach we are implementing with the Meta feature.
> > So as I see it, the logic should be something like this:
> > 1. run devconfigure.
> > 2. allocate mempool
> > 3. setup queues.
> > 4. run rte_flow_validate with mark action.
> > If flow validated register mark in mbuf else don't register.
> > If the PMD needs some special setting for mark he can update the queue when he gets the flow to validate.
> > At this stage the device is not started so any change is allowed.
> 
> I understand why there is capability reporting in rte_flow API when
> it is about rte_flow API itself. The problem appears when rte_flow
> API starts to interact with other functionality.
> Which pattern/actions should application try in order to decide
> if MARK is supported or not.

Why application should decide whether MARK is supported or not?
In my understanding it can be enabled dynamically per flow.

> The right answer is a pattern/action
> which will be really used, but what to do if there are many
> combinations or if these combinations are not know in advance.
> Minimal? But I easily imagine cases when minimal is not supported,
> but more complex real life patterns are supported.
> 
> The main idea behind the offload is as much as you know in advance
> as much you can optimize without overcomplicating drivers and HW.
> 
> In the case of OVS, absence MARK offload would mean that OVS
> should not even try to use partial offload even if it is enabled.
> So, no efforts are required to try to convert flow into pattern and
> validate the flow rule.

That's an interesting feedback.
I would like to understand why OVS cannot adapt its datapath on demand
per port, per queue and per flow?



  reply index

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-25 15:21 pbhagavatula
2019-10-25 15:21 ` [dpdk-dev] [PATCH 2/2] drivers/net: update Rx flow flag and mark capabilities pbhagavatula
2019-10-28 10:50 ` [dpdk-dev] [PATCH 1/2] ethdev: add flow action type update as an offload Ori Kam
2019-10-28 11:53   ` Andrew Rybchenko
2019-10-28 14:00     ` Ori Kam
2019-10-31  9:49       ` Andrew Rybchenko
2019-10-31 14:49         ` Thomas Monjalon [this message]
2019-10-31 23:59           ` Zhang, Qi Z
2019-11-01 11:35           ` Andrew Rybchenko
2019-11-03 10:22             ` Ori Kam
2019-11-03 11:41               ` Andrew Rybchenko
2019-11-04 18:37                 ` Ori Kam
2019-11-05  6:50                   ` Andrew Rybchenko
2019-11-05  8:35                     ` Ori Kam
2019-11-05 11:30                       ` Andrew Rybchenko
2019-11-05 16:37                         ` Ori Kam
2019-11-06  6:40                           ` Andrew Rybchenko
2019-11-06  7:42                             ` Ori Kam
2019-11-08  8:35                               ` Andrew Rybchenko
2019-11-08  9:00                                 ` Tom Barbette
2019-11-08 10:28                                 ` Thomas Monjalon
2019-11-08 10:42                                   ` Andrew Rybchenko
2019-11-08 11:03                                     ` Thomas Monjalon
2019-11-08 11:40                                       ` Zhang, Qi Z
2019-11-08 12:12                                         ` Ori Kam
2019-11-08 12:20                                           ` Andrew Rybchenko
2019-11-08 12:42                                             ` Ori Kam
2019-11-08 13:16                                               ` Zhang, Qi Z
2019-11-08 13:26                                                 ` Thomas Monjalon
2019-11-08 13:06                                         ` Thomas Monjalon
2019-11-08 12:00                                       ` Andrew Rybchenko
2019-11-08 13:17                                         ` Thomas Monjalon
2019-11-08 13:27                                           ` Andrew Rybchenko
2019-11-08 13:30                                             ` Thomas Monjalon
2019-11-19  9:24                                               ` Andrew Rybchenko
2019-11-19  9:50                                                 ` Thomas Monjalon
2019-11-19 10:59                                                   ` Andrew Rybchenko
2019-11-19 11:09                                                     ` Thomas Monjalon
2020-07-03 14:34                                                       ` Ferruh Yigit

Reply instructions:

You may reply publically 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=3078181.9TjvbByyqQ@xps \
    --to=thomas@monjalon.net \
    --cc=adrien.mazarguil@6wind.com \
    --cc=arybchenko@solarflare.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jerinj@marvell.com \
    --cc=john.mcnamara@intel.com \
    --cc=ktraynor@redhat.com \
    --cc=marko.kovacevic@intel.com \
    --cc=orika@mellanox.com \
    --cc=pbhagavatula@marvell.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

DPDK patches and discussions

Archives are clonable:
	git clone --mirror http://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ http://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev


Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/ public-inbox