[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpWo4YyVjoHdDdKLCXu_XO7=H8-2yet3qq6g3BUPtUbW4w@mail.gmail.com>
Date: Mon, 18 Jul 2016 10:38:19 -0700
From: Cong Wang <xiyou.wangcong@...il.com>
To: Jamal Hadi Salim <jhs@...atatu.com>
Cc: Thomas Graf <tgraf@...g.ch>,
Daniel Borkmann <daniel@...earbox.net>,
Alexei Starovoitov <alexei.starovoitov@...il.com>,
David Miller <davem@...emloft.net>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Subject: Re: [PATCH net-next 1/1] net_sched: Introduce skbmod action
On Mon, Jul 18, 2016 at 3:26 AM, Jamal Hadi Salim <jhs@...atatu.com> wrote:
> On 16-07-18 06:07 AM, Thomas Graf wrote:
>
>>
>> Right. I was at the same point as Jamal and it is nasty to try and
>> reverse engineer the dumps without any further hints. I assume that's
>> what he is referring to with difficulties.
>>
>
> That +: if you get me a field which says "dstmac" i dont have to go
> and start aggregating 32bit chunks to create a 48bit MAC (or worse
> look at the offset and figure where they come from).
>
Been there, done that. I debugged u32 filter dumps too, I understand
your concern.
But this still looks like solvable to me, although it is definitely not easy,
probably even harder than the parsing logic. I will try to write some
code for iproute2 to see how far I can go.
Adding a new type of action/filter in kernel just for convenience seems
overkill. At very least I think we should just extend the existing ones,
for example, allowing pedit to accept and dump DST_MAC etc. Does this
sound good to you?
Thanks.
Powered by blists - more mailing lists