On 17-04-24 06:24 PM, David Miller wrote:
I think we should eat the pain now and use the strict checks
for all new features like this.
I'm sorry if this makes more work for you, but this is really
how we have to proceed moving forward.
There is no work for me to do in tc if i push this in
From: Jamal Hadi Salim
Date: Mon, 24 Apr 2017 18:18:42 -0400
> With the posted patch: unknow bits set will result in a kernel
> rejection unless the user space explicitly ask the kernel to ignore
> flags it doesnt understand and just handles what it knows. This
> reduces the
On 17-04-24 04:30 PM, David Miller wrote:
Which is fine. But two things:
1) Again, bits you aren't using now, make sure userspace doesn't
set them. And if it does, reject.
I meet those goals on the bit checks but i went a slightly different
path with a patch I posted[1]
With the
From: Jamal Hadi Salim
Date: Mon, 24 Apr 2017 08:49:00 -0400
> Yes, space is important and if i can express upto 32 flags
> with one TLV rather than 32 TLVs i choose one TLV.
Which is fine. But two things:
1) Again, bits you aren't using now, make sure userspace doesn't
On 17-04-24 10:20 AM, Pablo Neira Ayuso wrote:
On Mon, Apr 24, 2017 at 08:49:00AM -0400, Jamal Hadi Salim wrote:
I am fine with the counter-Postel view of having the kernel
validate that appropriate bits are set as long as we dont make
user space to now start learning how to play acrobatics.
On Mon, Apr 24, 2017 at 08:49:00AM -0400, Jamal Hadi Salim wrote:
> On 17-04-24 05:14 AM, Simon Horman wrote:
> [..]
>
> >Jamal, I am confused about why are you so concerned about the space
> >consumed by this attribute, it's per-message, right? Is it the bigger
> >picture you are worried about -
On 17-04-24 05:14 AM, Simon Horman wrote:
[..]
Jamal, I am confused about why are you so concerned about the space
consumed by this attribute, it's per-message, right? Is it the bigger
picture you are worried about - a similar per-entry flag at some point in
the future?
To me the two worries
On Thu, Apr 20, 2017 at 04:24:53PM +0200, Jiri Pirko wrote:
> Thu, Apr 20, 2017 at 04:18:50PM CEST, j...@mojatatu.com wrote:
> >On 17-04-20 09:59 AM, Jiri Pirko wrote:
> >> Thu, Apr 20, 2017 at 03:06:21PM CEST, j...@mojatatu.com wrote:
> >> > From: Jamal Hadi Salim
...
> >> >
On 17-04-20 12:09 PM, Eric Dumazet wrote:
On Thu, 2017-04-20 at 09:06 -0400, Jamal Hadi Salim wrote:
nest = nla_nest_start(skb, TCA_ACT_TAB);
if (nest == NULL)
@@ -1113,6 +1136,8 @@ static int tc_dump_action(struct sk_buff *skb, struct
netlink_callback *cb)
if (ret >
On Thu, 2017-04-20 at 09:06 -0400, Jamal Hadi Salim wrote:
> nest = nla_nest_start(skb, TCA_ACT_TAB);
> if (nest == NULL)
> @@ -1113,6 +1136,8 @@ static int tc_dump_action(struct sk_buff *skb, struct
> netlink_callback *cb)
> if (ret > 0) {
> nla_nest_end(skb,
Thu, Apr 20, 2017 at 05:08:20PM CEST, j...@mojatatu.com wrote:
>On 17-04-20 10:33 AM, Jiri Pirko wrote:
>> Thu, Apr 20, 2017 at 04:25:11PM CEST, j...@mojatatu.com wrote:
>
>> > > TCAA stands for "traffic control action action". I don't get it :(
>> >
>> > TC Action Attributes == TCAA.
>> >
>> >
On 17-04-20 10:33 AM, Jiri Pirko wrote:
Thu, Apr 20, 2017 at 04:25:11PM CEST, j...@mojatatu.com wrote:
TCAA stands for "traffic control action action". I don't get it :(
TC Action Attributes == TCAA.
Prefix still sounds wrong to me, sorry :/
Should be:
TCA_SOMETHING_*
TCA_ATTR_XXX ?
Thu, Apr 20, 2017 at 04:25:11PM CEST, j...@mojatatu.com wrote:
>On 17-04-20 09:59 AM, Jiri Pirko wrote:
>> Thu, Apr 20, 2017 at 03:06:21PM CEST, j...@mojatatu.com wrote:
>> > From: Jamal Hadi Salim
>> >
>> > When you dump hundreds of thousands of actions, getting only 32 per
Thu, Apr 20, 2017 at 04:18:50PM CEST, j...@mojatatu.com wrote:
>On 17-04-20 09:59 AM, Jiri Pirko wrote:
>> Thu, Apr 20, 2017 at 03:06:21PM CEST, j...@mojatatu.com wrote:
>> > From: Jamal Hadi Salim
>> >
>> > When you dump hundreds of thousands of actions, getting only 32 per
On 17-04-20 09:59 AM, Jiri Pirko wrote:
Thu, Apr 20, 2017 at 03:06:21PM CEST, j...@mojatatu.com wrote:
From: Jamal Hadi Salim
When you dump hundreds of thousands of actions, getting only 32 per
dump batch even when the socket buffer and memory allocations allow
is
On 17-04-20 09:59 AM, Jiri Pirko wrote:
Thu, Apr 20, 2017 at 03:06:21PM CEST, j...@mojatatu.com wrote:
From: Jamal Hadi Salim
When you dump hundreds of thousands of actions, getting only 32 per
dump batch even when the socket buffer and memory allocations allow
is
Thu, Apr 20, 2017 at 03:06:21PM CEST, j...@mojatatu.com wrote:
>From: Jamal Hadi Salim
>
>When you dump hundreds of thousands of actions, getting only 32 per
>dump batch even when the socket buffer and memory allocations allow
>is inefficient.
>
>With this change, the user will
From: Jamal Hadi Salim
When you dump hundreds of thousands of actions, getting only 32 per
dump batch even when the socket buffer and memory allocations allow
is inefficient.
With this change, the user will get as many as possibly fitting
within the given constraints
18 matches
Mail list logo