From: Paul Blakey
Date: Wed, 25 Sep 2019 18:02:35 +0300
> This a new feature, it is preferred that it defaults to N.
> We will probe the feature support from userspace before actually using it.
>
> Fixes: 95a7233c452a ('net: openvswitch: Set OvS recirc_id from tc chain
> index')
> Signed-off-by
On 26/09/2019 16:14, Paul Blakey wrote:
> On 9/26/2019 5:26 PM, Edward Cree wrote:
>> On 26/09/2019 14:56, Paul Blakey wrote:
> In nat scenarios the packet will be modified, and then there can be a
> miss:
>
> -trk CT(zone X, Restore NAT),goto chain 1
>
>
On 9/26/2019 5:26 PM, Edward Cree wrote:
> On 26/09/2019 14:56, Paul Blakey wrote:
In nat scenarios the packet will be modified, and then there can be a miss:
-trk CT(zone X, Restore NAT),goto chain 1
+trk+est, match on ipv4, CT(zone Y), go
On 26/09/2019 14:56, Paul Blakey wrote:
>>> In nat scenarios the packet will be modified, and then there can be a miss:
>>>
>>> -trk CT(zone X, Restore NAT),goto chain 1
>>>
>>> +trk+est, match on ipv4, CT(zone Y), goto chain 2
>>>
>>> +trk+est, output..
On 9/26/2019 4:09 PM, Edward Cree wrote:
> On 26/09/2019 08:30, Paul Blakey wrote:
>> Ok, I thought you meant merging the rules because we do want to support
>> those modifications use-cases.
> I think the point is that your use-case is sufficiently weird and
> obscure that code in the core to s
On 26/09/2019 08:30, Paul Blakey wrote:
> Ok, I thought you meant merging the rules because we do want to support
> those modifications use-cases.
I think the point is that your use-case is sufficiently weird and
obscure that code in the core to support it needs to be unintrusive;
and this clear
On 9/25/2019 8:01 PM, Edward Cree wrote:
> On 24/09/2019 12:48, Paul Blakey wrote:
>> The 'miss' for all or nothing is easy, but the hard part is combining
>> all the paths a packet can take in software to a single 'all or nothing'
>> rule in hardware.
> But you don't combine them to a single rule
On 24/09/2019 12:48, Paul Blakey wrote:
> The 'miss' for all or nothing is easy, but the hard part is combining
> all the paths a packet can take in software to a single 'all or nothing'
> rule in hardware.
But you don't combine them to a single rule in hardware, because you
have multiple sequen
This a new feature, it is preferred that it defaults to N.
We will probe the feature support from userspace before actually using it.
Fixes: 95a7233c452a ('net: openvswitch: Set OvS recirc_id from tc chain index')
Signed-off-by: Paul Blakey
---
Changelog:
v1->v2: Changed target to net.
From: Paul Blakey
Date: Wed, 25 Sep 2019 15:28:29 +0300
> This a new feature, it is preferred that it defaults to N.
> We will probe the feature support from userspace before actually using it.
>
> Fixes: 95a7233c452a ('net: openvswitch: Set OvS recirc_id from tc chain
> index')
> Signed-off-by
This a new feature, it is preferred that it defaults to N.
We will probe the feature support from userspace before actually using it.
Fixes: 95a7233c452a ('net: openvswitch: Set OvS recirc_id from tc chain index')
Signed-off-by: Paul Blakey
---
net/sched/Kconfig | 1 -
1 file changed, 1 deletion
On 9/23/2019 8:17 PM, Edward Cree wrote:
> On 23/09/2019 17:56, Paul Blakey wrote:
>> Even following this approach in tc only is challenging for some
>> scenarios, consider the following tc rules:
>>
>> tc filter add dev1 ... chain 0 flower action goto chain 1
>> tc filter add dev1 ... chain 0 fl
On Sun, Sep 22, 2019 at 02:47:15PM -0700, Jakub Kicinski wrote:
> On Sun, 22 Sep 2019 14:51:44 +0300, Paul Blakey wrote:
...
> >
> >
> > Subject: [PATCH net-next] net/sched: Set default of CONFIG_NET_TC_SKB_EXT
>
On 23/09/2019 17:56, Paul Blakey wrote:
> Even following this approach in tc only is challenging for some
> scenarios, consider the following tc rules:
>
> tc filter add dev1 ... chain 0 flower action goto chain 1
> tc filter add dev1 ... chain 0 flower action goto chain 1
> tc filter add dev1 .
ftware backing (unless you merge the ct
table) and add them to the mix.
A single point of unsupported match/action between those, and we won't be able
to offload the entire path, we might
even spend a lot of resources (trying to merge) before we even know it can't be
offloaded, instead of doing what we can support.
>> -
tached patch.
Partial offloads are very hard. Could we possibly take a page out of
routing offload's book and do a all or nothing offload in presence of
multiple chains?
>
>
> Subject: [PATCH net-next] net/sched: Set default
N and letting users
decide to enable it, see attached patch.
Thanks,
Paul.
Subject: [PATCH net-next] net/sched: Set default of CONFIG_NET_TC_SKB_EXT to N
This a new feature, it is prefered that it defaults to N.
Fixes: 95a7233c45
On Sat, Sep 21, 2019 at 8:15 PM Pravin Shelar wrote:
> > > Any suggestions on the way forward? :(
since there is no clear and agreed by everyone path forward the simple
revert is the best option.
Next release cycle you can come up with something that works for everyone.
On Fri, Sep 20, 2019 at 5:06 PM Daniel Borkmann wrote:
>
> On 9/21/19 12:56 AM, Jakub Kicinski wrote:
> [...]
> >> I thought idea of stuffing things into skb extensions are only justified if
> >> it's not enabled by default for everyone. :(
> >>
> >> [0]
> >> https://lore.kernel.org/netdev/ca
On 9/21/19 12:56 AM, Jakub Kicinski wrote:
[...]
I thought idea of stuffing things into skb extensions are only justified if
it's not enabled by default for everyone. :(
[0]
https://lore.kernel.org/netdev/cahc9vhsz1_ka1tcjtnjwk26bokghkgbpt7v1o82mwpduvww...@mail.gmail.com/T/#u
The skb ext
CONFIG_NET_TC_SKB_EXT
is really not acceptable.
It should not be enabled by default at all.
Instead the actual users should turn it on or depend upon it, which in
this case seems to be OVS.
Please fix this, thank you.
Hi David,
We are working on it, but Paul is OoO today. Is it okay if we
On Sat, 21 Sep 2019 00:15:16 +0200, Daniel Borkmann wrote:
> On 9/20/19 6:16 PM, Jakub Kicinski wrote:
> > On Thu, 19 Sep 2019 15:13:55 +, Vlad Buslov wrote:
> >> On Thu 19 Sep 2019 at 14:21, David Miller wrote:
> >>> As Linus pointed out, the Kconfig l
On 9/20/19 6:16 PM, Jakub Kicinski wrote:
On Thu, 19 Sep 2019 15:13:55 +, Vlad Buslov wrote:
On Thu 19 Sep 2019 at 14:21, David Miller wrote:
As Linus pointed out, the Kconfig logic for CONFIG_NET_TC_SKB_EXT
is really not acceptable.
It should not be enabled by default at all.
Instead
On Thu, 19 Sep 2019 15:13:55 +, Vlad Buslov wrote:
> On Thu 19 Sep 2019 at 14:21, David Miller wrote:
> > As Linus pointed out, the Kconfig logic for CONFIG_NET_TC_SKB_EXT
> > is really not acceptable.
> >
> > It should not be enabled by default at all.
> >
&g
On Thu 19 Sep 2019 at 14:21, David Miller wrote:
> As Linus pointed out, the Kconfig logic for CONFIG_NET_TC_SKB_EXT
> is really not acceptable.
>
> It should not be enabled by default at all.
>
> Instead the actual users should turn it on or depend upon it, which in
> this
As Linus pointed out, the Kconfig logic for CONFIG_NET_TC_SKB_EXT
is really not acceptable.
It should not be enabled by default at all.
Instead the actual users should turn it on or depend upon it, which in
this case seems to be OVS.
Please fix this, thank you.
26 matches
Mail list logo
