netdev - Re: [net 4/8] net/mlx5e: Don't allow aRFS for encapsulated packets

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: <CAKHjkjm8-hf5LEYZpYVGO_RhJrAXqwtiDu4Ya4ohzGez_UdxTg@mail.gmail.com>
Date:   Thu, 19 Jul 2018 12:02:08 +0300
From:   Eran Ben Elisha <eranlinuxmellanox@...il.com>
To:     Or Gerlitz <gerlitz.or@...il.com>
Cc:     Saeed Mahameed <saeedm@...lanox.com>,
        Eran Ben Elisha <eranbe@...lanox.com>,
        "David S. Miller" <davem@...emloft.net>,
        Linux Netdev List <netdev@...r.kernel.org>,
        Alexander Duyck <alexander.h.duyck@...el.com>,
        Tom Herbert <tom@...bertland.com>
Subject: Re: [net 4/8] net/mlx5e: Don't allow aRFS for encapsulated packets

On Thu, Jul 19, 2018 at 10:50 AM, Or Gerlitz <gerlitz.or@...il.com> wrote:
> On Thu, Jul 19, 2018 at 9:55 AM, Eran Ben Elisha
> <eranlinuxmellanox@...il.com> wrote:
>> On Thu, Jul 19, 2018 at 9:23 AM, Or Gerlitz <gerlitz.or@...il.com> wrote:
>>> On Thu, Jul 19, 2018 at 4:26 AM, Saeed Mahameed <saeedm@...lanox.com> wrote:
>>>> From: Eran Ben Elisha <eranbe@...lanox.com>
>>>>
>>>> Driver is yet to support aRFS for encapsulated packets, return early
>>>> error in such case.
>>>
>>>
>>> Eran,
>>>
>>> Isn't that something which is done wrong by the arfs stack code?
>>>
>>> If the kernel has an SKB which has encap set and an arfs steering
>>> rule is programed into the driver, the API should include a driver neutral
>>> description for the encap header for the HW to match, so maybe we can just do
>>>
>>
>> Hi Or,
>> This could break existing drivers support for tunneled aRFS, and hurts
>> their RX performance dramatically..
>
>> IMHO, it is expected from the driver to figure out that the skb holds
>> encap packet and act accordingly.
>
> I don't think this one bit indication on the skb is enough for
> any HW driver (e.g mlx4, mlx5 and others) to properly set
> the steering rules.

why do you think it is not enough?
mlx5e currently cannot offload tunneled packets, so this info is
perfectly fit in order to reject.

>
> The problem you indicate typically doesn't come into play in the presence
> of VMs, since the host TCP stack isn't active on such traffic.
>
> This is maybe why it wasn't pointed earlier.
>
> I believe that more drivers are broken (mlx4?)

We can do a fix for that latter.

>
> Looking now on bnxt, I see they dissect the skb and then check the
> FLOW_DIS_ENCAPSULATION flag but not always err.
>
> If we want to make sure we don't break anyone else, we can indeed have
> the check done in our drivers.
>
> It seems that the check done by bnxt is more general, thoughts?

I see bnxt driver checking protocol using this mechanism as well,
in mlx5e it was selected via skb metadata, let's keep going with this approach.

>
> Or.