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
