On 17-01-17 06:53 AM, Paul Blakey wrote:
Should be "trivial" like my patch.
Add a new TLV type in TCA_XXX enum in rtnetlink.h
in tc_ctl_tfilter look for it and memcpy it
in tcf_fill_node set it on the new TCA_XXX if the cls struct
has it present.
That's exactly what I did before I reali
On 17/01/2017 13:23, Jamal Hadi Salim wrote:
On 17-01-16 04:51 AM, Jiri Pirko wrote:
Mon, Jan 16, 2017 at 08:54:18AM CET, pa...@mellanox.com wrote:
I think we should do it in a generic way, for every classifier, right
away. Same as Jamal is doing for actions. I think that first we shoul
On 17-01-16 04:51 AM, Jiri Pirko wrote:
Mon, Jan 16, 2017 at 08:54:18AM CET, pa...@mellanox.com wrote:
I think we should do it in a generic way, for every classifier, right
away. Same as Jamal is doing for actions. I think that first we should
get Jamal's patch merged and then do the same
Mon, Jan 16, 2017 at 08:54:18AM CET, pa...@mellanox.com wrote:
>
>
>On 15/01/2017 21:08, John Fastabend wrote:
>> On 17-01-15 09:36 AM, Paul Blakey wrote:
>> >
>> >
>> > On 08/01/2017 19:12, Jiri Pirko wrote:
>> > > Mon, Jan 02, 2017 at 03:59:49PM CET, j...@mojatatu.com wrote:
>> > > >
>> > > >
On 15/01/2017 21:08, John Fastabend wrote:
On 17-01-15 09:36 AM, Paul Blakey wrote:
On 08/01/2017 19:12, Jiri Pirko wrote:
Mon, Jan 02, 2017 at 03:59:49PM CET, j...@mojatatu.com wrote:
We have been using a cookie as well for actions (which we have been
using but have been too lazy to subm
On 17-01-15 09:36 AM, Paul Blakey wrote:
>
>
> On 08/01/2017 19:12, Jiri Pirko wrote:
>> Mon, Jan 02, 2017 at 03:59:49PM CET, j...@mojatatu.com wrote:
>>>
>>> We have been using a cookie as well for actions (which we have been
>>> using but have been too lazy to submit so far). I am going to port
On 08/01/2017 19:12, Jiri Pirko wrote:
Mon, Jan 02, 2017 at 03:59:49PM CET, j...@mojatatu.com wrote:
We have been using a cookie as well for actions (which we have been
using but have been too lazy to submit so far). I am going to port
it over to the newer kernels and post it.
Hard to deal
On 17-01-14 10:29 AM, Jiri Pirko wrote:
Sat, Jan 14, 2017 at 04:03:17PM CET, j...@mojatatu.com wrote:
Fair. So could this be done like IFLA_PHYS_SWITCH_ID and
IFLA_PHYS_PORT_ID. They can have variable size, max is MAX_PHYS_ITEM_ID_LEN
We can let user to pass arbitrary len up to 16 bytes. This
Sat, Jan 14, 2017 at 04:03:17PM CET, j...@mojatatu.com wrote:
>On 17-01-14 09:48 AM, Jiri Pirko wrote:
>> Sat, Jan 14, 2017 at 01:56:35PM CET, j...@mojatatu.com wrote:
>
>
>> > I think the feature makes a lot of sense (as is the action variant).
>> > But can we make it:
>> > a) fixed size
>>
>> Ca
On 17-01-14 09:48 AM, Jiri Pirko wrote:
Sat, Jan 14, 2017 at 01:56:35PM CET, j...@mojatatu.com wrote:
I think the feature makes a lot of sense (as is the action variant).
But can we make it:
a) fixed size
Can you elaborate on why is this needed?
My experience with the action bits its eas
Sat, Jan 14, 2017 at 01:56:35PM CET, j...@mojatatu.com wrote:
>On 17-01-09 01:23 PM, John Fastabend wrote:
>> On 17-01-08 09:19 AM, Jiri Pirko wrote:
>
>[..]
>> > This should never be interpreted by kernel. I think this would be good
>> > to make clear in the comment in the code.
>> >
>>
>> Ah OK
On 17-01-03 07:22 AM, Paul Blakey wrote:
I don't mind having it on TC level but I didn't want to intervene with
all filters/TC.
Please do make it for all classifiers. I described a use case for u32
where the cookie could be used to pretty print the output on a
dump/get.
cheers,
jamal
On 17-01-09 01:23 PM, John Fastabend wrote:
On 17-01-08 09:19 AM, Jiri Pirko wrote:
[..]
This should never be interpreted by kernel. I think this would be good
to make clear in the comment in the code.
Ah OK I had assumed you would be pushing this via tc_cls_flower_offload into
the driver i
On 17-01-08 09:19 AM, Jiri Pirko wrote:
> Mon, Jan 02, 2017 at 11:21:41PM CET, j...@mojatatu.com wrote:
>> On 17-01-02 01:23 PM, John Fastabend wrote:
>>
>>>
>>> Additionally I would like to point out this is an arbitrary length binary
>>> blob (for undefined use, without even a specified encoding)
Mon, Jan 02, 2017 at 11:21:41PM CET, j...@mojatatu.com wrote:
>On 17-01-02 01:23 PM, John Fastabend wrote:
>
>>
>> Additionally I would like to point out this is an arbitrary length binary
>> blob (for undefined use, without even a specified encoding) that gets pushed
>> between user space and har
Mon, Jan 02, 2017 at 07:23:27PM CET, john.fastab...@gmail.com wrote:
>On 17-01-02 06:59 AM, Jamal Hadi Salim wrote:
>>
>> We have been using a cookie as well for actions (which we have been
>> using but have been too lazy to submit so far). I am going to port
>> it over to the newer kernels and po
Mon, Jan 02, 2017 at 03:59:49PM CET, j...@mojatatu.com wrote:
>
>We have been using a cookie as well for actions (which we have been
>using but have been too lazy to submit so far). I am going to port
>it over to the newer kernels and post it.
Hard to deal with something we can't look at :)
>In
On Wed, Jan 04, 2017 at 01:45:28PM +0200, Paul Blakey wrote:
> On 04/01/2017 12:14, Simon Horman wrote:
> >On Tue, Jan 03, 2017 at 02:22:05PM +0200, Paul Blakey wrote:
> >>
> >>On 03/01/2017 13:44, Jamal Hadi Salim wrote:
> >>>On 17-01-02 11:33 PM, John Fastabend wrote:
> On 17-01-02 05:22 PM,
On 04/01/2017 12:14, Simon Horman wrote:
On Tue, Jan 03, 2017 at 02:22:05PM +0200, Paul Blakey wrote:
On 03/01/2017 13:44, Jamal Hadi Salim wrote:
On 17-01-02 11:33 PM, John Fastabend wrote:
On 17-01-02 05:22 PM, Jamal Hadi Salim wrote:
[..]
Like all cookie semantics it is for storing sta
On Tue, Jan 03, 2017 at 02:22:05PM +0200, Paul Blakey wrote:
>
>
> On 03/01/2017 13:44, Jamal Hadi Salim wrote:
> >On 17-01-02 11:33 PM, John Fastabend wrote:
> >>On 17-01-02 05:22 PM, Jamal Hadi Salim wrote:
> >
> >[..]
> >>>Like all cookie semantics it is for storing state. The receiver
> >>>(k
On 03/01/2017 13:44, Jamal Hadi Salim wrote:
On 17-01-02 11:33 PM, John Fastabend wrote:
On 17-01-02 05:22 PM, Jamal Hadi Salim wrote:
[..]
Like all cookie semantics it is for storing state. The receiver
(kernel)
is not just store it and not intepret it. The user when reading it back
simpl
On 17-01-02 11:33 PM, John Fastabend wrote:
On 17-01-02 05:22 PM, Jamal Hadi Salim wrote:
[..]
Like all cookie semantics it is for storing state. The receiver (kernel)
is not just store it and not intepret it. The user when reading it back
simplifies what they have to do for their processing.
On 17-01-02 05:22 PM, Jamal Hadi Salim wrote:
> On 17-01-02 05:58 PM, John Fastabend wrote:
>> On 17-01-02 02:21 PM, Jamal Hadi Salim wrote:
>
>
>> Well having the length value avoids ending up with cookie1, cookie2, ...
>> values as folks push more and more data into the cookie.
>>
>
> Unless t
On 17-01-02 05:58 PM, John Fastabend wrote:
On 17-01-02 02:21 PM, Jamal Hadi Salim wrote:
Well having the length value avoids ending up with cookie1, cookie2, ...
values as folks push more and more data into the cookie.
Unless there is good reason I dont see why it shouldnt be a fixed leng
On 17-01-02 02:21 PM, Jamal Hadi Salim wrote:
> On 17-01-02 01:23 PM, John Fastabend wrote:
>
>>
>> Additionally I would like to point out this is an arbitrary length binary
>> blob (for undefined use, without even a specified encoding) that gets pushed
>> between user space and hardware ;) This s
On 17-01-02 01:23 PM, John Fastabend wrote:
Additionally I would like to point out this is an arbitrary length binary
blob (for undefined use, without even a specified encoding) that gets pushed
between user space and hardware ;) This seemed to get folks fairly excited in
the past.
The binar
On 17-01-02 06:59 AM, Jamal Hadi Salim wrote:
>
> We have been using a cookie as well for actions (which we have been
> using but have been too lazy to submit so far). I am going to port
> it over to the newer kernels and post it.
> In our case that is intended to be opaque to the kernel i.e kerne
We have been using a cookie as well for actions (which we have been
using but have been too lazy to submit so far). I am going to port
it over to the newer kernels and post it.
In our case that is intended to be opaque to the kernel i.e kernel
never inteprets it; in that case it is similar to the
This is to support saving extra data that might be helpful on retrieval.
First use case is upcoming openvswitch flow offloads, extra data will
include UFID and port mappings for each added flow.
Signed-off-by: Paul Blakey
Reviewed-by: Roi Dayan
Acked-by: Jiri Pirko
---
include/uapi/linux/pkt_c
29 matches
Mail list logo
