Hi, this is an old thread, but I'll reply to this instead of the RFC v2 since
there is more context here.
Thanks for pushing the new api forward Adrien.
-john daley
> > >>> - Match range of Physical Functions (PFs) on the NIC in a single rule
> > >>> via masks. For ex: match all traffic coming
On Tue, Aug 09, 2016 at 02:47:44PM -0700, John Fastabend wrote:
> On 16-08-04 06:24 AM, Adrien Mazarguil wrote:
> > On Wed, Aug 03, 2016 at 12:11:56PM -0700, John Fastabend wrote:
[...]
> >> The problem is keeping priorities in order and/or possibly breaking
> >> rules apart (e.g. you have an L2
On Tue, Aug 09, 2016 at 02:24:26PM -0700, John Fastabend wrote:
[...]
> > Just an idea, could some kind of meta pattern items specifying time
> > constraints for a rule address this issue? Say, how long (cycles/ms) the PMD
> > may take to query/apply/delete the rule. If it cannot be guaranteed,
On 16-08-10 06:37 AM, Adrien Mazarguil wrote:
> On Tue, Aug 09, 2016 at 02:47:44PM -0700, John Fastabend wrote:
>> On 16-08-04 06:24 AM, Adrien Mazarguil wrote:
>>> On Wed, Aug 03, 2016 at 12:11:56PM -0700, John Fastabend wrote:
> [...]
The problem is keeping priorities in order and/or
On 16-08-10 04:02 AM, Adrien Mazarguil wrote:
> On Tue, Aug 09, 2016 at 02:24:26PM -0700, John Fastabend wrote:
> [...]
>>> Just an idea, could some kind of meta pattern items specifying time
>>> constraints for a rule address this issue? Say, how long (cycles/ms) the PMD
>>> may take to
On 16-08-04 06:24 AM, Adrien Mazarguil wrote:
> On Wed, Aug 03, 2016 at 12:11:56PM -0700, John Fastabend wrote:
>> [...]
>>
The proposal looks very good. It satisfies most of the features
supported by Chelsio NICs. We are looking for suggestions on exposing
more
[...]
>> I'm not sure I understand 'bit granularity' here. I would say we have
>> devices now that have rather strange restrictions due to hardware
>> implementation. Going forward we should get better hardware and a lot
>> of this will go away in my view. Yes this is a long term view and
>>
On Wed, Aug 03, 2016 at 12:11:56PM -0700, John Fastabend wrote:
> [...]
>
> >> The proposal looks very good. It satisfies most of the features
> >> supported by Chelsio NICs. We are looking for suggestions on exposing
> >> more additional features supported by Chelsio NICs via this
On Wed, Aug 03, 2016 at 11:10:49AM -0700, John Fastabend wrote:
> [...]
>
> Considering that allowed pattern/actions combinations cannot be known in
> advance and would result in an unpractically large number of
> capabilities to
> expose, a method is provided to validate a
Replying to everything at once, please see below.
On Tue, Jul 26, 2016 at 03:37:35PM +0530, Rahul Lakkireddy wrote:
> On Monday, July 07/25/16, 2016 at 09:40:02 -0700, John Fastabend wrote:
> > On 16-07-25 04:32 AM, Rahul Lakkireddy wrote:
> > > Hi Adrien,
> > >
> > > On Thursday, July 07/21/16,
Hi Kieran,
On Mon, Aug 01, 2016 at 04:08:51PM +0100, Kieran Mansley wrote:
> Apologies for coming a little late to this thread about the proposed new
> API for filtering etc.
>
> I've reviewed it based on Solarflare's needs and hardware capabilities,
> and think the proposal is likely to be a
Hi John,
I'm replying below to both messages.
On Tue, Aug 02, 2016 at 11:19:15AM -0700, John Fastabend wrote:
> On 16-07-23 02:10 PM, John Fastabend wrote:
> > On 16-07-21 12:20 PM, Adrien Mazarguil wrote:
> >> Hi Jerin,
> >>
> >> Sorry, looks like I missed your reply. Please see below.
> >>
> >
[...]
>> The proposal looks very good. It satisfies most of the features
>> supported by Chelsio NICs. We are looking for suggestions on exposing
>> more additional features supported by Chelsio NICs via this API.
>>
>> Chelsio NICs have two regions in which filters can be
[...]
Considering that allowed pattern/actions combinations cannot be known in
advance and would result in an unpractically large number of capabilities
to
expose, a method is provided to validate a given rule from the current
device configuration state without actually
On 16-07-23 02:10 PM, John Fastabend wrote:
> On 16-07-21 12:20 PM, Adrien Mazarguil wrote:
>> Hi Jerin,
>>
>> Sorry, looks like I missed your reply. Please see below.
>>
>
> Hi Adrian,
>
> Sorry for a bit delay but a few comments that may be worth considering.
>
> To start with completely
Apologies for coming a little late to this thread about the proposed new
API for filtering etc.
I've reviewed it based on Solarflare's needs and hardware capabilities,
and think the proposal is likely to be a big improvement on the current
system.
I worry slightly that the goal of having
On Monday, July 07/25/16, 2016 at 09:40:02 -0700, John Fastabend wrote:
> On 16-07-25 04:32 AM, Rahul Lakkireddy wrote:
> > Hi Adrien,
> >
> > On Thursday, July 07/21/16, 2016 at 19:07:38 +0200, Adrien Mazarguil wrote:
> >> Hi Rahul,
> >>
> >> Please see below.
> >>
> >> On Thu, Jul 21, 2016 at
On 16-07-25 04:32 AM, Rahul Lakkireddy wrote:
> Hi Adrien,
>
> On Thursday, July 07/21/16, 2016 at 19:07:38 +0200, Adrien Mazarguil wrote:
>> Hi Rahul,
>>
>> Please see below.
>>
>> On Thu, Jul 21, 2016 at 01:43:37PM +0530, Rahul Lakkireddy wrote:
>>> Hi Adrien,
>>>
>>> The proposal looks very
On 16-07-21 12:20 PM, Adrien Mazarguil wrote:
> Hi Jerin,
>
> Sorry, looks like I missed your reply. Please see below.
>
Hi Adrian,
Sorry for a bit delay but a few comments that may be worth considering.
To start with completely agree on the general problem statement and the
nice summary of
n Jacob
> ; De Lara Guarch, Pablo
> ; Olga Shern ;
> Chilikin, Andrey
> Subject: Re: [dpdk-dev] [RFC] Generic flow director/filtering/classification
> API
>
> Hi Sugesh,
>
> I do not have much to add, please see below.
>
> On Thu, Jul 21, 2016 at 11:06:52AM
Hi Adrien,
> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com]
> Sent: Thursday, July 21, 2016 8:48 PM
> To: Lu, Wenzhuo
> Cc: dev at dpdk.org; Thomas Monjalon; Zhang, Helin; Wu, Jingjing; Rasesh Mody;
> Ajit Khaparde; Rahul Lakkireddy; Jan Medala; John
Hi Jerin,
Sorry, looks like I missed your reply. Please see below.
On Mon, Jul 11, 2016 at 04:11:43PM +0530, Jerin Jacob wrote:
> On Tue, Jul 05, 2016 at 08:16:46PM +0200, Adrien Mazarguil wrote:
>
> Hi Adrien,
>
> Overall this proposal looks very good. I could easily map to the
>
Hi Rahul,
Please see below.
On Thu, Jul 21, 2016 at 01:43:37PM +0530, Rahul Lakkireddy wrote:
> Hi Adrien,
>
> The proposal looks very good. It satisfies most of the features
> supported by Chelsio NICs. We are looking for suggestions on exposing
> more additional features supported by
Hi Adrien,
The proposal looks very good. It satisfies most of the features
supported by Chelsio NICs. We are looking for suggestions on exposing
more additional features supported by Chelsio NICs via this API.
Chelsio NICs have two regions in which filters can be placed -
Maskfull and Maskless
in, Andrey
> Subject: Re: [dpdk-dev] [RFC] Generic flow director/filtering/classification
> API
>
> Hi Sugesh,
>
> Please see below.
>
> On Wed, Jul 20, 2016 at 04:32:50PM +, Chandran, Sugesh wrote:
> [...]
> > > > How about a hardware flow flag in pac
Hi Adrien,
> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com]
> Sent: Wednesday, July 20, 2016 6:41 PM
> To: Lu, Wenzhuo
> Cc: dev at dpdk.org; Thomas Monjalon; Zhang, Helin; Wu, Jingjing; Rasesh Mody;
> Ajit Khaparde; Rahul Lakkireddy; Jan Medala; John
Hi Sugesh,
Please see below.
On Wed, Jul 20, 2016 at 04:32:50PM +, Chandran, Sugesh wrote:
[...]
> > > How about a hardware flow flag in packet descriptor that set when the
> > > packets hits any hardware rule. This way software doesn?t worry
> > > /blocked by a hardware rule . Even though
; Olga Shern ;
> Chilikin, Andrey
> Subject: Re: [dpdk-dev] [RFC] Generic flow director/filtering/classification
> API
>
> On Mon, Jul 18, 2016 at 01:26:09PM +, Chandran, Sugesh wrote:
> > Hi Adrien,
> > Thank you for getting back on this.
> > Please find my c
Hi Wenzhuo,
On Wed, Jul 20, 2016 at 02:16:51AM +, Lu, Wenzhuo wrote:
[...]
> > So, today an application cannot combine N-tuple and FDIR flow rules and get
> > a
> > reliable outcome, unless it is designed for specific devices with a known
> > behavior.
> >
> > > What's the right behavior of
Hi Adrien,
> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com]
> Sent: Tuesday, July 19, 2016 9:12 PM
> To: Lu, Wenzhuo
> Cc: dev at dpdk.org; Thomas Monjalon; Zhang, Helin; Wu, Jingjing; Rasesh Mody;
> Ajit Khaparde; Rahul Lakkireddy; Jan Medala; John
On Tue, Jul 19, 2016 at 08:11:48AM +, Lu, Wenzhuo wrote:
> Hi Adrien,
> Thanks for your clarification. Most of my questions are clear, but still
> something may need to be discussed, comment below.
Hi Wenzhuo,
Please see below.
[...]
> > > > Requirements for a new API:
> > > >
> > > > -
Hi Adrien,
Thanks for your clarification. Most of my questions are clear, but still
something may need to be discussed, comment below.
> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com]
> Sent: Thursday, July 7, 2016 6:27 PM
> To: Lu, Wenzhuo
> Cc: dev
On Mon, Jul 18, 2016 at 01:26:09PM +, Chandran, Sugesh wrote:
> Hi Adrien,
> Thank you for getting back on this.
> Please find my comments below.
Hi Sugesh,
Same for me, removed again the parts we agree on.
[...]
> > > > > > > [Sugesh] Another concern is the cost and time of installing
> >
gt; ; Olga Shern ;
> Chilikin, Andrey
> Subject: Re: [dpdk-dev] [RFC] Generic flow director/filtering/classification
> API
>
> On Fri, Jul 15, 2016 at 09:23:26AM +, Chandran, Sugesh wrote:
> > Thank you Adrien,
> > Please find below for some more comments/inputs
Khaparde ; Rahul Lakkireddy
> ; Lu, Wenzhuo ;
> Jan Medala ; John Daley ; Chen,
> Jing D ; Ananyev, Konstantin
> ; Matej Vido ;
> Alejandro Lucero ; Sony Chacko
> ; Jerin Jacob
> ; De Lara Guarch, Pablo
> ; Olga Shern
> Subject: RE: [dpdk-dev] [RFC] Generic flow
On Fri, Jul 15, 2016 at 09:23:26AM +, Chandran, Sugesh wrote:
> Thank you Adrien,
> Please find below for some more comments/inputs
>
> Let me know your thoughts on this.
Thanks, stripping again non relevant parts.
[...]
> > > > > [Sugesh] Is it a limitation to use only 32 bit ID? Is it
Hi Sugesh,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Chandran, Sugesh
> Sent: Friday, July 15, 2016 10:23 AM
> To: 'Adrien Mazarguil'
> > > > To PMD maintainers: please comment if you know devices that
> > > > support tagging matching packets with
b
> ; De Lara Guarch, Pablo
> ; Olga Shern
> Subject: Re: [dpdk-dev] [RFC] Generic flow director/filtering/classification
> API
>
> On Mon, Jul 11, 2016 at 10:42:36AM +, Chandran, Sugesh wrote:
> > Hi Adrien,
> >
> > Thank you for your response,
> > Pl
On Mon, Jul 11, 2016 at 10:42:36AM +, Chandran, Sugesh wrote:
> Hi Adrien,
>
> Thank you for your response,
> Please see my comments inline.
Hi Sugesh,
Sorry for the delay, please see my answers inline as well.
[...]
> > > > Flow director
> > > > -
> > > >
> > > > Flow director
On Tue, Jul 05, 2016 at 08:16:46PM +0200, Adrien Mazarguil wrote:
Hi Adrien,
Overall this proposal looks very good. I could easily map to the
classification hardware engines I am familiar with.
> Priorities
> ~~
>
> A priority can be assigned to a matching pattern.
>
> The default
On Mon, Jul 11, 2016 at 03:18:19AM +, Liang, Cunming wrote:
[...]
> > > >When several actions are combined in a flow rule, they should all have
> > > >different types (e.g. dropping a packet twice is not possible). However
> > > >considering the VOID type is an exception to this rule, the
sesh
> > > Mody ; Ajit Khaparde
> > > ; Rahul Lakkireddy
> > > ; Lu, Wenzhuo
> ;
> > > Jan Medala ; John Daley ;
> Chen,
> > > Jing D ; Ananyev, Konstantin
> > > ; Matej Vido ;
> > > Alejandro Lucero ; Sony Chacko
> > > ; Jeri
Rasesh
> Mody ; Ajit Khaparde
> ; Rahul Lakkireddy
> ; Lu, Wenzhuo ; Jan
> Medala ; John Daley ; Chen, Jing D
> ; Ananyev, Konstantin
> ; Matej Vido ;
> Alejandro Lucero ; Sony Chacko
> ; Jerin Jacob ;
> De
> Lara Guarch, Pablo ; Olga Shern
>
> Subj
Hi Adrien,
On 7/6/2016 2:16 AM, Adrien Mazarguil wrote:
> Hi All,
>
> First, forgive me for this large message, I know our mailboxes already
> suffer quite a bit from the amount of traffic on this ML.
>
> This is not exactly yet another thread about how flow director should be
> extended, rather
Hi Cunming,
I agree with Bruce, I'll start snipping non relevant parts considering the
size of this message. Please see below.
On Fri, Jul 08, 2016 at 07:11:28PM +0800, Liang, Cunming wrote:
[...]
> >Meta item types
> >~~~
> >
> >These do not match packet data but affect how the
> Alejandro Lucero ; Sony Chacko
> > ; Jerin Jacob
> > ; De Lara Guarch, Pablo
> > ; Olga Shern
> > Subject: [dpdk-dev] [RFC] Generic flow director/filtering/classification API
> >
> > Hi All,
> >
> > First, forgive me for this large message, I know
On Fri, Jul 08, 2016 at 07:11:28PM +0800, Liang, Cunming wrote:
Please Cunming, when replying in the middle of a long email - of which this
is a perfect example - delete the large chunks of content you are not replying
to. I had to page down multiple times to find the new comments you wrote, and
Lu, Wenzhuo ;
> Jan Medala ; John Daley ; Chen,
> Jing D ; Ananyev, Konstantin
> ; Matej Vido ;
> Alejandro Lucero ; Sony Chacko
> ; Jerin Jacob
> ; De Lara Guarch, Pablo
> ; Olga Shern
> Subject: [dpdk-dev] [RFC] Generic flow director/filtering/classification API
>
>
Hi Lu Wenzhuo,
Thanks for your feedback, I'm replying below as well.
On Thu, Jul 07, 2016 at 07:14:18AM +, Lu, Wenzhuo wrote:
> Hi Adrien,
> I have some questions, please see inline, thanks.
>
> > -Original Message-
> > From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com]
>
Hi Adrien,
I have some questions, please see inline, thanks.
> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com]
> Sent: Wednesday, July 6, 2016 2:17 AM
> To: dev at dpdk.org
> Cc: Thomas Monjalon; Zhang, Helin; Wu, Jingjing; Rasesh Mody; Ajit Khaparde;
>
Hi All,
First, forgive me for this large message, I know our mailboxes already
suffer quite a bit from the amount of traffic on this ML.
This is not exactly yet another thread about how flow director should be
extended, rather about a brand new API to handle filtering and
classification for
51 matches
Mail list logo
