On 2019-05-22 2:23 p.m., Jamal Hadi Salim wrote:
On 2019-05-22 1:49 p.m., Vlad Buslov wrote:
On Wed 22 May 2019 at 20:24, Jamal Hadi Salim wrote:
Ok, thanks for chasing this. A test case i had in mind is to
maybe have 3 actions. Add the drop in the middle for one
and at the begging for anot
On 2019-05-22 1:49 p.m., Vlad Buslov wrote:
On Wed 22 May 2019 at 20:24, Jamal Hadi Salim wrote:
Ok, thanks for chasing this. A test case i had in mind is to
maybe have 3 actions. Add the drop in the middle for one
and at the begging for another and see if they are visible
with the patch.
If
On Wed 22 May 2019 at 20:24, Jamal Hadi Salim wrote:
> On 2019-05-22 11:08 a.m., Vlad Buslov wrote:
>>
>> On Tue 21 May 2019 at 16:23, Vlad Buslov wrote:
>
>>
>> It seems that culprit in this case is tc_action->order field. It is used
>> as nla attrtype when dumping actions. Initially it is set
On 2019-05-22 11:08 a.m., Vlad Buslov wrote:
On Tue 21 May 2019 at 16:23, Vlad Buslov wrote:
It seems that culprit in this case is tc_action->order field. It is used
as nla attrtype when dumping actions. Initially it is set according to
ordering of actions of filter that creates them. Howev
On Tue 21 May 2019 at 16:23, Vlad Buslov wrote:
> On Tue 21 May 2019 at 15:46, Jamal Hadi Salim wrote:
>> On 2019-05-20 5:12 p.m., Jamal Hadi Salim wrote:
>>> On 2019-05-20 2:36 p.m., Edward Cree wrote:
On 20/05/2019 17:29, Jamal Hadi Salim wrote:
>>
>>> Ok, so the "get" does it. Will try t
On Tue 21 May 2019 at 15:46, Jamal Hadi Salim wrote:
> On 2019-05-20 5:12 p.m., Jamal Hadi Salim wrote:
>> On 2019-05-20 2:36 p.m., Edward Cree wrote:
>>> On 20/05/2019 17:29, Jamal Hadi Salim wrote:
>
>> Ok, so the "get" does it. Will try to reproduce when i get some
>> cycles. Meantime CCing Co
On 2019-05-20 5:12 p.m., Jamal Hadi Salim wrote:
On 2019-05-20 2:36 p.m., Edward Cree wrote:
On 20/05/2019 17:29, Jamal Hadi Salim wrote:
Ok, so the "get" does it. Will try to reproduce when i get some
cycles. Meantime CCing Cong and Vlad.
I have reproduced it in a simpler setup. See atta
On 2019-05-20 2:36 p.m., Edward Cree wrote:
On 20/05/2019 17:29, Jamal Hadi Salim wrote:
Maybe dump after each step and it will be easier to see what is
happening.
I don't *think* my changes can have caused this, but I'll try a test on a
vanilla kernel just to make sure the same thing happe
On 20/05/2019 17:29, Jamal Hadi Salim wrote:
> Maybe dump after each step and it will be easier to see what is
> happening.
>
>> I don't *think* my changes can have caused this, but I'll try a test on a
>> vanilla kernel just to make sure the same thing happens there.
>
> Possible an offload bug
On 20/05/2019 17:29, Jamal Hadi Salim wrote:
> On 2019-05-20 12:10 p.m., Edward Cree wrote:
>> # tc filter del dev $vfrep parent : pref 49151
>> # tc -stats filter show dev $vfrep parent :
>> filter protocol arp pref 49152 flower chain 0
>> filter protocol arp pref 49152 flower chain 0 hand
On 2019-05-20 12:29 p.m., Jamal Hadi Salim wrote:
Assuming in this case you added by value the actions?
To be clear on the terminology:
"By Value" implies you add the filter and action in the
same command line.
"By Reference" implies you first create the action then
create a filter which binds
On 2019-05-20 12:10 p.m., Edward Cree wrote:
On 20/05/2019 16:38, Jamal Hadi Salim wrote:
That is fine then if i could do:
tc actions add action drop index 104
then
followed by for example the two filters you show below..
That seems to work.
nice.
Is your hardware not using explicit indic
On 20/05/2019 16:38, Jamal Hadi Salim wrote:
> That is fine then if i could do:
>
> tc actions add action drop index 104
> then
> followed by for example the two filters you show below..
That seems to work.
> Is your hardware not using explicit indices into a stats table?
No; we ask the HW to allo
On Mon, May 20, 2019 at 04:37:10PM +0100, Edward Cree wrote:
> On 19/05/2019 01:22, Pablo Neira Ayuso wrote:
> > On Fri, May 17, 2019 at 04:27:29PM +0100, Edward Cree wrote:
> >> On 15/05/2019 20:39, Edward Cree wrote:
> > [...]
> >> Pablo, how do the two options interact with your netfilter offloa
On 2019-05-20 11:37 a.m., Edward Cree wrote:
On 19/05/2019 01:22, Pablo Neira Ayuso wrote:
On Fri, May 17, 2019 at 04:27:29PM +0100, Edward Cree wrote:
Thanks. Looking at net/netfilter/nfnetlink_acct.c, it looks as though you
don't have a u32 index in there; for the cookie approach, would
On 2019-05-20 11:26 a.m., Edward Cree wrote:
On 18/05/2019 21:39, Jamal Hadi Salim wrote:
On 2019-05-17 1:14 p.m., Edward Cree wrote:
On 17/05/2019 16:27, Edward Cree wrote:
Unless *I* missed something, I'm not changing the TC<=>user-space API at
all. If user space specifies an index, the
On 19/05/2019 01:22, Pablo Neira Ayuso wrote:
> On Fri, May 17, 2019 at 04:27:29PM +0100, Edward Cree wrote:
>> On 15/05/2019 20:39, Edward Cree wrote:
> [...]
>> Pablo, how do the two options interact with your netfilter offload? I'm
>> guessing it's easier for you to find a unique pointer than
On 18/05/2019 21:39, Jamal Hadi Salim wrote:
> On 2019-05-17 1:14 p.m., Edward Cree wrote:
>> On 17/05/2019 16:27, Edward Cree wrote:
>>> I'm now leaning towards the
>>> approach of adding "unsigned long cookie" to struct flow_action_entry
>>> and populating it with (unsigned long)act in tc_set
On Fri, May 17, 2019 at 04:27:29PM +0100, Edward Cree wrote:
> On 15/05/2019 20:39, Edward Cree wrote:
[...]
> Pablo, how do the two options interact with your netfilter offload? I'm
> guessing it's easier for you to find a unique pointer than to generate
> a unique u32 action_index for each act
On 2019-05-17 1:14 p.m., Edward Cree wrote:
On 17/05/2019 16:27, Edward Cree wrote:
I'm now leaning towards the
approach of adding "unsigned long cookie" to struct flow_action_entry
and populating it with (unsigned long)act in tc_setup_flow_action().
For concreteness, here's what that look
On 2019-05-15 3:39 p.m., Edward Cree wrote:
[..]
A point for discussion: would it be better if, instead of the tcfa_index
(for which the driver has to know the rules about which flow_action
types share a namespace), we had some kind of globally unique cookie?
In the same way that rule->coo
On 17/05/2019 16:27, Edward Cree wrote:
> I'm now leaning towards the
> approach of adding "unsigned long cookie" to struct flow_action_entry
> and populating it with (unsigned long)act in tc_setup_flow_action().
For concreteness, here's what that looks like: patch 1 is replaced with
the follow
On 15/05/2019 20:39, Edward Cree wrote:
> A point for discussion: would it be better if, instead of the tcfa_index
> (for which the driver has to know the rules about which flow_action
> types share a namespace), we had some kind of globally unique cookie?
> In the same way that rule->cookie is
When the flow_offload infrastructure was added, per-action statistics,
which were previously possible for drivers to support in TC offload,
were not plumbed through, perhaps because the drivers in the tree did
not implement them.
In TC (and in the previous offload API) statistics are per-action,
24 matches
Mail list logo
