Sat, May 27, 2017 at 07:18:45PM CEST, t...@herbertland.com wrote:
>On Sat, May 27, 2017 at 9:31 AM, Or Gerlitz <gerlitz...@gmail.com> wrote:
>> On Thu, May 25, 2017 at 7:22 PM, Tom Herbert <t...@herbertland.com> wrote:
>>> On Thu, May 25, 2017 at 6:24 AM, Or Gerlitz <ogerl...@mellanox.com> wrote:
>>>> Add support for dissection of ip tos and ttl and ipv6 traffic-class
>>>> and hoplimit. Both are dissected into the same struct.
>>
>>>> Uses similar call to ip dissection function as with tcp, arp and others.
>>
>>
>>>> +/**
>>>> + * struct flow_dissector_key_ip:
>>>> + * @tos: tos
>>>> + * @ttl: ttl
>>>> + */
>>>> +struct flow_dissector_key_ip {
>>>> + __u8 tos;
>>>> + __u8 ttl;
>>>> +};
>>>> --- a/net/core/flow_dissector.c
>>>> +++ b/net/core/flow_dissector.c
>>
>>>> +static void
>>>> +__skb_flow_dissect_ipv4(const struct sk_buff *skb,
>>>> + struct flow_dissector *flow_dissector,
>>>> + void *target_container, void *data, const struct
>>>> iphdr *iph)
>>>> +{
>>>> + struct flow_dissector_key_ip *key_ip;
>>>> +
>>>> + if (!dissector_uses_key(flow_dissector, FLOW_DISSECTOR_KEY_IP))
>>>> + return;
>>>> +
>>>> + key_ip = skb_flow_dissector_target(flow_dissector,
>>>> + FLOW_DISSECTOR_KEY_IP,
>>>> + target_container);
>>>> + key_ip->tos = iph->tos;
>>>> + key_ip->ttl = iph->ttl;
>>>
>>> In an encapsulation this returns the tos and ttl of the encapsulated
>>> packet. Is that really useful to the caller? Seems more likely that
>>> they need the outer tos and ttl for forwarding.
>>
>> In what we are dealing with, classification is carried after the
>> packet is decapsulated by the shared tunnel device. So even today,e.g
>> for the src/dst IP, the dissection is carried on what were the inner
>> fields before decap.
>>
>Or,
>
>I think the problem is I don't know what you're dealing with. The only
>thing I can derive from the commit log is that tos and ttl are being
>extracted, but I don't know why they are needed. I do know this is
>adding complexity to an already overly complex function, and this
>introduces new conditionals and code into the primary use case of
>flow_dissector which is to create a key for deriving skb->hash. I
>don't see that the cost of this patch has been justified.
Tom, we have been over this multiple times. The decision DaveM made at
the time I was pushing cls_flower was to have one shared dissection code
(I originally had a separate dissector inside cls_flower). And I
agree with that decision. It was a bit painful to work out the
flow_dissector in a generic way, but it was worth the efford.
So when we need to dissect something new for cls_flower, we put it here.
flow_dissector is now miles away from being just a plain
"creator of the key to derive skb->hash".
Jiří
