Messages in this thread | | | Date | Tue, 24 Jun 2014 10:14:55 +0200 | From | Daniel Borkmann <> | Subject | Re: [PATCH v6 net-next 1/4] net: flow_dissector: avoid multiple calls in eBPF |
| |
On 06/20/2014 11:56 PM, Chema Gonzalez wrote: ... >>>> Anyway as I said before I'm not excited about either. >>>> I don't think we should be adding classic BPF extensions any more. >>>> The long term headache of supporting classic BPF extensions >>>> outweighs the short term benefits. >>> >>> I see a couple of issues with (effectively) freezing classic BPF >>> development while waiting for direct eBPF access to happen. The first >>> one is that the kernel has to accept it. I can see many questions >>> about this, especially security and usability (I'll send an email >>> about the "split BPF out of core later"). Now, the main issue is >>> whether/when the tools will support it. IMO, this is useful iff I can >>> quickly write/reuse filters and run tcpdump filters based on them. I'm >>> trying to get upstream libpcap to accept support for raw (classic) BPF >>> filters, and it's taking a long time. I can imagine how they may be >>> less receptive about supporting a Linux-only eBPF mechanism. Tools do >>> matter. > > This is a high-level decision, more than a technical one. Do we want > to freeze classic BPF development in linux, even before we have a > complete eBPF replacement, and zero eBPF tool (libpcap) support?
In my opinion, I don't think we strictly have to hard-freeze it. The only concern I see is that conceptually hooking into the flow_dissector to read out all keys for further processing on top of them 1) sort of breaks/bypasses the concept of BPF (as it's actually the task of BPF itself for doing this), 2) effectively freezes any changes to the flow_dissector as BPF applications making use of it now depend on the provided offsets for doing further processing on top of them, 3) it can already be resolved by (re-)writing the kernel's flow dissector in C-like syntax in user space iff eBPF can be loaded from there with similar performance. So shouldn't we rather work towards that as a more generic approach/goal in the mid term and w/o having to maintain a very short term intermediate solution that we need to special case along the code and have to carry around forever ...
>> Grepping through libpcap code, which tries to be platform independent, >> it seems after all the years, the only thing where you can see support >> for in their code is SKF_AD_PKTTYPE and SKF_AD_PROTOCOL. Perhaps they > > Actually they recently added MOD/XOR support. Woo-hoo!
Great to hear, still quite some things missing, unfortunately. :/
>> just don't care, perhaps they do, who knows, but it looks to me a bit >> that they are reluctant to these improvements, maybe for one reason >> that other OSes don't support it. > > From the comments in the MOD/XOR patch, the latter seem to be the issue.
Yep, that's the pain you need to live with when trying to be multi OS capable. I assume in its very origin, the [libpcap] compiler was probably not designed for handling such differences in various operating systems (likely even ran in user space from libpcap directly).
>> That was also one of the reasons that >> led me to start writing bpf_asm (net/tools/) for having a small DSL >> for more easily trying out BPF code while having _full_ control over it. >> >> Maybe someone should start a binary-compatible Linux-only version of >> libpcap, where tcpdump will transparently make use of these low level >> improvements eventually. </rant> ;) > > There's too much code dependent on libpcap to make a replacement possible.
Well, I wrote binary-compatible, so applications on top of it won't care much if it could be used as drop-in replacement. That would perhaps also allow for fanout and other features to be used ...
| |