Re: [RFC v2 6/6] flow_dissector: Parse batman-adv unicast headers

[Sven Eckelmann <sven.eckelmann@openmesh.com>]

[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]

On Dienstag, 5. Dezember 2017 09:19:45 CET Tom Herbert wrote:
[...]
> Switch statements with cases having many LOC is hard to read and
> __skb_flow_dissect is aleady quite convoluted to begin with.
> 
> I suggest putting this in a static function similar to how MPLS and
> GRE are handled.

Thanks for the feedback.

I was not sure whether "inline" or an extra function would be preferred. I've 
then decided to implement it like most of the other protocols. But since an 
extra function is the preferred method for handling new protos, I will move it 
to an extra function.

The change can already be found in
 https://git.open-mesh.org/linux-merge.git/shortlog/refs/heads/ecsv/flowdissector

I also saw that you've introduced in
commit 823b96939578 ("flow_dissector: Add control/reporting of encapsulation") 
a flag to stop dissecting when something encapsulated was detected. It is not 
100% clear to me when the  FLOW_DIS_ENCAPSULATION should be set and 
FLOW_DISSECTOR_F_STOP_AT_ENCAP be checked. Only when there is IP/eth in IP 
(like in the two examples from the commit message) or also when there is a 
ethernet header, followed by batman-adv unicast header and again followed by 
an ethernet header?

Right now, the flag FLOW_DISSECTOR_F_STOP_AT_ENCAP is only used by 
fib_multipath_hash - so it doesn't really help me to understand it. But the 
FLOW_DIS_ENCAPSULATION is checked by drivers/net/ethernet/broadcom/bnxt/bnxt.c
to set it in a special tunnel_type (anytunnel) mode for IPv4/IPv6 packets. So 
my (wild) guess right now is that these flags should only be used/checked when 
handling encapsulation inside IPv4/IPv6 packets. But maybe you can correct me 
here.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]