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
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
> > to N
> >
> > This a
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 .
On 9/23/2019 12:47 AM, Jakub Kicinski wrote:
> On Sun, 22 Sep 2019 14:51:44 +0300, Paul Blakey wrote:
>> The skb extension is currently used for miss path of software offloading OvS
>> rules with recirculation to tc.
>> However, we are also preparing patches to support the hardware side of
>> th
On Sun, 22 Sep 2019 14:51:44 +0300, Paul Blakey wrote:
> The skb extension is currently used for miss path of software offloading OvS
> rules with recirculation to tc.
> However, we are also preparing patches to support the hardware side of things.
>
> After the userspace OvS patches to support c
The skb extension is currently used for miss path of software offloading OvS
rules with recirculation to tc.
However, we are also preparing patches to support the hardware side of things.
After the userspace OvS patches to support connection tracking, we'll have two
users for
tc multi chain rule
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
On 9/21/19 12:56 AM, Jakub Kicinski wrote:
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 logic for
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 logic for CONFIG_NET_TC_SKB_EXT
> >>>
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 th
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 the actual users should
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 case seems to be OVS.
21 matches
Mail list logo
