From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Thomas Graf <tgraf@suug.ch>, Daniel Borkmann <daniel@iogearbox.net>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
davem@davemloft.net, netdev@vger.kernel.org,
xiyou.wangcong@gmail.com, nikolay@cumulusnetworks.com
Subject: Re: [PATCH net-next 1/1] net_sched: Introduce skbmod action
Date: Mon, 18 Jul 2016 06:26:00 -0400 [thread overview]
Message-ID: <578CAEB8.9070805@mojatatu.com> (raw)
In-Reply-To: <20160718100717.GB30532@pox.localdomain>
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).
> 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.
>
A "cookie" tag that is sent to the kernel would serve the purpose.
We would need to standardize what the meaning of such a cookie is.
> 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.
>
Yes - and btw it works well with hardware offloads. It is a good free
form "assembler" level. But i dont think it serves well when we have
known often-used cases such as these.
It is like doing tcp over raw sockets - at some point it becomes more
efficient and more usable to just introduce tcp sockets. Thats all I
am asking for.
cheers,
jamal
next prev parent reply other threads:[~2016-07-18 10:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-17 8:41 [PATCH net-next 1/1] net_sched: Introduce skbmod action Jamal Hadi Salim
2016-07-18 4:19 ` Alexei Starovoitov
2016-07-18 6:51 ` Jamal Hadi Salim
2016-07-18 9:44 ` Daniel Borkmann
2016-07-18 10:07 ` Thomas Graf
2016-07-18 10:26 ` Jamal Hadi Salim [this message]
2016-07-18 17:38 ` Cong Wang
2016-07-19 10:28 ` Jamal Hadi Salim
2016-07-18 10:08 ` Jamal Hadi Salim
2016-07-19 13:21 ` Daniel Borkmann
2016-07-19 13:56 ` Jamal Hadi Salim
2016-07-19 15:03 ` Daniel Borkmann
2016-07-19 18:04 ` Cong Wang
2016-07-20 0:23 ` Daniel Borkmann
2016-07-21 7:27 ` WAS ( " Jamal Hadi Salim
2016-07-21 14:42 ` Daniel Borkmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=578CAEB8.9070805@mojatatu.com \
--to=jhs@mojatatu.com \
--cc=alexei.starovoitov@gmail.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=tgraf@suug.ch \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.