From: Edward Cree
Date: Thu, 17 Oct 2019 19:01:36 +0100
> On 17/10/2019 18:46, Pablo Neira Ayuso wrote:
>> Making this opt-in will just leave things as bad as they are right
>> now, with drivers that are very much hard to read.
> Again, there are two driver developers in this conversation, and th
From: Edward Cree
Date: Thu, 17 Oct 2019 18:59:22 +0100
> Pedit is supposed to work even in the absence of protocol knowledge in
> the kernel (e.g. in combination with cls_u32, you can filter and mangle
> traffic in a completely new protocol), you're turning it into Yet
> Another Ossified TCP/
On 17/10/2019 18:46, Pablo Neira Ayuso wrote:
> Making this opt-in will just leave things as bad as they are right
> now, with drivers that are very much hard to read.
Again, there are two driver developers in this conversation, and they
both disagree with you. Reflect on that fact.
On 17/10/2019 17:22, Pablo Neira Ayuso wrote:
> You refer to single u32 word changing both sport and dport.
>
> What's the point with including this in the subset of the uAPI to be
> supported?
What's the point with removing this from the uAPI which implicitly the
kernel internal layers supported
On Thu, Oct 17, 2019 at 10:30:59AM -0700, Jakub Kicinski wrote:
[...]
> Ed requested this was a opt-in/helper the driver can call if they
> choose to. Please do that. Please provide selftests.
I will follow up to support for mangling two ports with one single u32
word, no problem.
Making this
On Thu, 17 Oct 2019 18:11:57 +0200, Pablo Neira Ayuso wrote:
> Hello Jakub,
>
> On Wed, Oct 16, 2019 at 04:36:51PM -0700, Jakub Kicinski wrote:
> > Let's see if I can recount the facts:
> > (1) this is a "improvement" to simplify driver work but driver
> > developers (Ed and I) don't like it
On Thu, Oct 17, 2019 at 06:11:57PM +0200, Pablo Neira Ayuso wrote:
[...]
> > (3) it causes loss of functionality (looks like a single u32 changing
> > both sport and dport is rejected by the IR since it wouldn't
> > match fields);
>
> Not correct.
>
> tc filter add dev eth0 protocol ip
Hello Jakub,
On Wed, Oct 16, 2019 at 04:36:51PM -0700, Jakub Kicinski wrote:
> Let's see if I can recount the facts:
> (1) this is a "improvement" to simplify driver work but driver
> developers (Ed and I) don't like it;
Ed requested to support for partial mangling of header fields. This
pa
On Tue, 15 Oct 2019 00:10:50 +0200, Pablo Neira Ayuso wrote:
> The flow mangle action is originally modeled after the tc pedit action,
> this has a number of shortcomings:
>
> 1) The tc pedit offset must be set on the 32-bits boundaries. Many
>protocol header field offsets are not aligned to 3
Hi Pablo,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
[cannot apply to v5.4-rc3 next-20191014]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specif
The flow mangle action is originally modeled after the tc pedit action,
this has a number of shortcomings:
1) The tc pedit offset must be set on the 32-bits boundaries. Many
protocol header field offsets are not aligned to 32-bits, eg. port
destination, port source and ethernet destination.
11 matches
Mail list logo
