From: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Kumar A S <kumaras@chelsio.com>,
Nirranjan Kirubaharan <nirranjan@chelsio.com>
Subject: Re: [dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and new behavior switch to fdir
Date: Thu, 25 Feb 2016 15:03:24 +0530 [thread overview]
Message-ID: <20160225093322.GB10077@chelsio.com> (raw)
In-Reply-To: <3102616.xnBgmsEaQs@xps13>
Hi Thomas,
On Wednesday, February 02/24/16, 2016 at 14:17:58 -0800, Thomas Monjalon wrote:
> Caution: I truly respect the work done by Chelsio on DPDK.
Thank you. And Chelsio will continue to support DPDK community and will
continue to contribute.
> And I'm sure you can help to build a good filtering API, which
> was mainly designed with Intel needs in mind because it was
> difficult to have opinions of other vendors some time ago.
> That's why it's a chance to have new needs and it would be a shame
> to let it go through a vendor specific backdoor.
I agree that new needs should be raised.
RFC v1 was submitted at:
http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/29986
RFC v2 was submitted at:
http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/30732
I tried to accomodate as many fields as possible to make this as generic as
possible. Also, I followed the review comments given by Jingjing.
I also waited for more review comments before posting this series to
see if there were any objections with the approach.
I have been trying to make this generic for all vendors and not favour
any one over the other.
>
> 2016-02-25 00:10, Rahul Lakkireddy:
> > Hi Thomas,
> >
> > On Wednesday, February 02/24/16, 2016 at 07:02:42 -0800, Thomas Monjalon wrote:
> > > 2016-02-24 14:43, Bruce Richardson:
> > > > On Wed, Feb 03, 2016 at 02:02:22PM +0530, Rahul Lakkireddy wrote:
> > > > > Add a new raw packet flow that allows specifying generic flow input.
> > > > >
> > > > > Add the ability to provide masks for fields in flow to allow range of
> > > > > values.
> > > > >
> > > > > Add a new behavior switch.
> > > > >
> > > > > Add the ability to provide behavior arguments to allow rewriting matched
> > > > > fields with new values. Ex: allows to provide new ip and port addresses
> > > > > to rewrite the fields of packets matching a filter rule before NAT'ing.
> > > > >
> > > > Thomas, any comments as ethdev maintainer?
> > >
> > > Yes, some comments.
> > > First, there are several different changes in the same patch. It must be split.
> >
> > Should each structure change be split into a separate patch?
>
> A patch = a feature.
> The switch action and the flow rule are different things.
Ok. I will split this into separate patches.
>
> > > Then I don't understand at all the raw flow filter. What is a raw flow?
> > > How behavior_arg must be used?
> >
> > This was discussed with Jingjing at
> >
> > http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/31471
>
> Thanks, I missed it.
>
> > A raw flow provides a generic way for vendors to add their vendor
> > specific input flow.
>
> Please, "generic" and "vendor specific" in the same sentence.
> It's obviously wrong.
I think this sentence is being mis-interpreted.
What I intended to say is: the fields are generic so that any vendor can
hook-in. The fields themselves are not vendor specific.
>
> > In our case, it is possible to match several flows
> > in a single rule. For example, it's possible to set an ethernet, vlan,
> > ip and tcp/udp flows all in a single rule. We can specify all of these
> > flows in a single raw input flow, which can then be passed to cxgbe flow
> > director to set the corresponding filter.
>
> I feel we need to define what is an API.
> If the application wants to call something specific to the NIC, why using
> the ethdev API? You just have to include cxgbe.h.
Well, in that sense, flow-director is also very intel specific, no ?
What we are trying to do is make flow-director generic and, we have been
following the review comments on this. If there are better ideas on how
to achieve this, we are open to suggestions/comments and are ready to
re-do the series and re-submit also.
>
> > On similar lines, behavior_arg provides a generic way to pass extra
> > action arguments for matched flows. For example, in our case, to
> > perform NAT, the new src/dst ip and src/dst port addresses to be
> > re-written for a matched rule can be passed in behavior_arg.
>
> Yes a kind of void* to give what you want to the driver without the
> convenience of a documented function.
void* approach was taken based on review comments from Jingjing.
And we didn't receive any further comments/objections on that thread.
>
> I know the support of filters among NICs is really heterogeneous.
> And the DPDK API are not yet generic enough. But please do not give up!
> If the filtering API can be improved to support your cases, please do it.
I am not giving up. If there are better suggestions then, I am willing
to re-do and re-submit the series.
If the approach taken in RFC v1 series looks more promising then, I can
re-surrect that also. However, I will need some direction over here so
that it becomes generic and doesn't remain intel specific as it is now.
Thanks,
Rahul.
next prev parent reply other threads:[~2016-02-25 9:33 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-03 8:32 [dpdk-dev] [PATCH 00/10] cxgbe: Add flow director support Rahul Lakkireddy
2016-02-03 8:32 ` [dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and new behavior switch to fdir Rahul Lakkireddy
2016-02-24 14:43 ` Bruce Richardson
2016-02-24 15:02 ` Thomas Monjalon
2016-02-24 18:40 ` Rahul Lakkireddy
2016-02-24 22:17 ` Thomas Monjalon
2016-02-25 9:33 ` Rahul Lakkireddy [this message]
2016-02-25 18:24 ` Thomas Monjalon
2016-02-26 1:17 ` Wu, Jingjing
2016-03-03 15:03 ` Olga Shern
2016-07-20 10:45 ` Thomas Monjalon
2016-02-25 3:26 ` Wu, Jingjing
2016-02-25 9:11 ` Rahul Lakkireddy
2016-02-03 8:32 ` [dpdk-dev] [PATCH 02/10] examples/test-cxgbe-filters: add example to test cxgbe fdir support Rahul Lakkireddy
2016-02-24 14:40 ` Bruce Richardson
2016-02-24 18:35 ` Rahul Lakkireddy
2016-02-25 13:48 ` Bruce Richardson
2016-02-03 8:32 ` [dpdk-dev] [PATCH 03/10] cxgbe: add skeleton to add support for T5 hardware filtering Rahul Lakkireddy
2016-02-03 8:32 ` [dpdk-dev] [PATCH 04/10] cxgbe: add control txq for communicating filtering info Rahul Lakkireddy
2016-02-03 8:32 ` [dpdk-dev] [PATCH 05/10] cxgbe: add compressed local IP table for matching IPv6 addresses Rahul Lakkireddy
2016-02-03 8:32 ` [dpdk-dev] [PATCH 06/10] cxgbe: add layer 2 table for switch action filter Rahul Lakkireddy
2016-02-03 8:32 ` [dpdk-dev] [PATCH 07/10] cxgbe: add source mac " Rahul Lakkireddy
2016-02-03 8:32 ` [dpdk-dev] [PATCH 08/10] cxgbe: add LE-TCAM filtering support Rahul Lakkireddy
2016-02-03 8:32 ` [dpdk-dev] [PATCH 09/10] cxgbe: add HASH " Rahul Lakkireddy
2016-02-03 8:32 ` [dpdk-dev] [PATCH 10/10] cxgbe: add flow director support and update documentation Rahul Lakkireddy
2016-02-22 10:39 ` [dpdk-dev] [PATCH 00/10] cxgbe: Add flow director support Rahul Lakkireddy
2016-03-22 13:43 ` Bruce Richardson
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=20160225093322.GB10077@chelsio.com \
--to=rahul.lakkireddy@chelsio.com \
--cc=dev@dpdk.org \
--cc=kumaras@chelsio.com \
--cc=nirranjan@chelsio.com \
--cc=thomas.monjalon@6wind.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).