All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Daniel Borkmann <daniel@iogearbox.net>, davem@davemloft.net
Cc: netdev@vger.kernel.org, xiyou.wangcong@gmail.com,
	alexei.starovoitov@gmail.com
Subject: Re: [net-next PATCH 0/5] net_sched: Add support for IFE action
Date: Thu, 25 Feb 2016 07:35:51 -0500	[thread overview]
Message-ID: <56CEF527.8040609@mojatatu.com> (raw)
In-Reply-To: <56CDEF43.1010402@iogearbox.net>

On 16-02-24 12:58 PM, Daniel Borkmann wrote:
> On 02/24/2016 01:49 PM, Jamal Hadi Salim wrote:

>> Yes, a bit of that ++.
>> I am between two worlds: There are people who do user space packet
>> processing that claim they do so because they can quickly prototype
>> without compiling the kernel. My goal is to make it easy for people
>> adding new metadata without having to deal with kernel recompile.
>
> Seems like a case for cls_bpf? ;)
>

Yes, and ebpf is a good answer in a few such discussions these days.

>
> Ok, sure, given the assumption that this is only to be used in your own
> fully _controlled_ environment anyway.

It is - typically in the same rack; but could be across to another
room.


> But in that case, you don't even
> need to define any fixed IDs. Currently it seems like you could have
> different kernel versions with different IFE_META_MAX from the kernel
> headers and external modules define part of the ID space differently?
>

That is part of the problem.
Dynamic registration is not going to work well without some
human supervision. We are talking about large number of endpoints.
One machine cannot guarantee to be interested in the same metadata
as others and as you say they could be different kernels etc.
Even within same organization across different groups would require
some  coordination.

I will take that module param out and maybe describe a set of IDs that
are for "private use" and let whoever is deploying worry about
coordination. For the rest i will just have some LANANA or IANA
or kernel maintainance issues them. I should declare all the obvious
kernel ones.

cheers,
jamal

  reply	other threads:[~2016-02-25 12:35 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-22 13:21 [net-next PATCH 0/5] net_sched: Add support for IFE action Jamal Hadi Salim
2016-02-22 13:21 ` [net-next PATCH 1/5] introduce " Jamal Hadi Salim
2016-02-22 13:21 ` [net-next PATCH 2/5] Support to encoding decoding skb mark on " Jamal Hadi Salim
2016-02-22 13:21 ` [net-next PATCH 3/5] Support to encoding decoding skb prio " Jamal Hadi Salim
2016-02-22 17:01   ` Daniel Borkmann
2016-02-22 13:21 ` [net-next PATCH 4/5] Support to encoding decoding skb hashid " Jamal Hadi Salim
2016-02-22 16:56   ` Daniel Borkmann
2016-02-22 13:21 ` [net-next PATCH 5/5] Support to encoding decoding skb queue map " Jamal Hadi Salim
2016-02-22 16:59   ` Daniel Borkmann
2016-02-22 21:03   ` John Fastabend
2016-02-23 12:17     ` Jamal Hadi Salim
2016-02-23 19:33       ` John Fastabend
2016-02-22 16:47 ` [net-next PATCH 0/5] net_sched: Add support for " Daniel Borkmann
2016-02-23 12:09   ` Jamal Hadi Salim
2016-02-23 13:20     ` Daniel Borkmann
2016-02-23 14:28       ` Jamal Hadi Salim
2016-02-23 15:34         ` Daniel Borkmann
2016-02-24 12:49           ` Jamal Hadi Salim
2016-02-24 17:48             ` Daniel Borkmann
2016-02-25 12:23               ` Jamal Hadi Salim
2016-02-25 21:34                 ` Daniel Borkmann
2016-02-25 22:40                   ` Jamal Hadi Salim
2016-02-26  0:03                     ` Daniel Borkmann
2016-02-24 17:58             ` Daniel Borkmann
2016-02-25 12:35               ` Jamal Hadi Salim [this message]
2016-02-23  7:00 ` Cong Wang
2016-02-23 12:18   ` Jamal Hadi Salim

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=56CEF527.8040609@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=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.