Thread (47 messages) 47 messages, 5 authors, 2014-06-27

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help