Re: [PATCH net-next v2] net: filter: add insn for loading internal transport header offset
From: Chema Gonzalez <hidden>
Date: 2014-05-05 18:42:01
On Fri, May 2, 2014 at 7:52 PM, David Miller [off-list ref] wrote:
quoted
Once you get the L3 proto and noff/toff, you get everything. The rationale of adding toff/noff is that it's very similar to poff, which we already have.But you're implementation is calling a function to do all of that work already, just to get only the transport header and then throwing away all of the other useful bits that function is calculating, so you'll end up doing it twice which is wasted work.
The problem here is that (classic) BPF works only with 2 registers. We need at least 2 fields to get a valid point in the packet, namely the offset and the protocol of the inner-most header (either L3 or L4). The idea of this patch is to run the flow dissector twice, once to get the protocol type, and a second to get the offset (this patch implements the offset part of the L4 header). This is 2 calls, but it provides flow dissection inside BPF. I guess we could have this call return 2 values, one in A, the other in X. This is strange in BPF, but we could do it (and then the user should probably push one of the values right away if she wants to use it later). Does it sound good?
We can probably add an extension to AF_PACKET which provides the flow key at the end of the tpacket3_hdr if a certain socket option is set. That would provide the transport header as well as a side effect, and be much more powerful and efficient than this particular BPF instruction.
I'm not sure whether I follow this. The goal is to be able to access the inner-most headers inside BPF, not in userland by calling getsockopt(). -Chema