[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160718100717.GB30532@pox.localdomain>
Date: Mon, 18 Jul 2016 12:07:18 +0200
From: Thomas Graf <tgraf@...g.ch>
To: Daniel Borkmann <daniel@...earbox.net>
Cc: Jamal Hadi Salim <jhs@...atatu.com>,
Alexei Starovoitov <alexei.starovoitov@...il.com>,
davem@...emloft.net, netdev@...r.kernel.org,
xiyou.wangcong@...il.com, nikolay@...ulusnetworks.com
Subject: Re: [PATCH net-next 1/1] net_sched: Introduce skbmod action
On 07/18/16 at 11:44am, Daniel Borkmann wrote:
> Same for tcp, icmp, ipv6 bits code ... :/ Is it still planned to eventually
> complete these? I agree that from a usability PoV, it might be nice to
> have some kind of 'pretty printer' for it besides the existing config
> parser there (e.g. when we know that a loaded instance was done with a
> high-level module, we could annotate that for retrieval on dump or such).
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.
Looking back, I would simply calculate a SHA hash over the original
filter in text form, pass the hash together with the tc filter and then
associate the hash with the filter text stored in user space. This
would not only benefit pedit but also u32 and possibly others.
It also has the advantage that extending the kernel once now will allow
to add additional higher level abstractions later on without requiring
users to rebase their kernels.
Powered by blists - more mailing lists