Just realized flow_keys_init() returns a zero'ed flow_keys, which is
not inited. I renamed the function flow_keys_reset(). Sending v3.

-Chema


On Wed, May 14, 2014 at 11:42 AM, Chema Gonzalez [off-list ref] wrote:

On Mon, May 5, 2014 at 12:12 PM, David Miller [off-list ref] wrote:

quoted

From: Chema Gonzalez <redacted>
Date: Mon, 5 May 2014 11:42:00 -0700

quoted

On Fri, May 2, 2014 at 7:52 PM, David Miller [off-list ref] wrote:

quoted

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().

You're missing my entire point.

You can use AF_PACKET mmap() rings and in those ring entries all of the
flow dissection information can be put in the ring entry headers before
the packet contents.  Ports, header offsets, everything.

I added a flow_keys variable in the packet runner function
(__sk_run_filter()) stack, and modified __skb_get_poff() to try to get
the results from there instead of calling the flow dissector every
time you call it. That will allow the packet filter to only perform a
single call to the flow dissector per packet.

I reworked the toff patch to use the same flow dissector output
approach (and share it with the poff load), and added a tproto patch.

Patches coming now.

-Chema