netdev - Re: [PATCH net-next 1/4] net/flow_dissector: add support for dissection of misc ip header fields

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJ3xEMhpwe9XXDU-6x1MLbAub9tZ6XMfh22zQj3sTshpTejGsQ@mail.gmail.com>
Date:   Sat, 27 May 2017 23:56:12 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Tom Herbert <tom@...bertland.com>
Cc:     Or Gerlitz <ogerlitz@...lanox.com>,
        "David S. Miller" <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Roi Dayan <roid@...lanox.com>, Paul Blakey <paulb@...lanox.com>
Subject: Re: [PATCH net-next 1/4] net/flow_dissector: add support for
 dissection of misc ip header fields

On Sat, May 27, 2017 at 8:18 PM, Tom Herbert <tom@...bertland.com> wrote:

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

The current case for matching on TTL I am dealing with is for using
TC/flower for offloading OVS in flow based VM traffic routing env
(Open-Stack and ODL
DVR - Distributed Virtual Routing) -- where packet headers are
re-written to set the next hop MACs and the TTL is changed. Fields
which are modified are also matched beforhand, and here comes the
matching on TTL.

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

I hear what you're saying, but part of the rules is that everything to
be offloaded can also be carried out in the kernel SW data-path, so
here comes the touching that area. I have used the minimal foot print
I could and set the code to run in a separate helper called from the
main dissection function.

>> When we did the the flower patches for being able to classify on both
>> the inner and outer fields (say outer src/dst ip, tunnel key) for what
>> related to the  macs/ips/ports/etc -- I don't think we touched the
>> existing dissection, I will look on that to see if I am wrong..