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: <CAJ3xEMivDFLfrXpXWj_t6tHbk7apfHrgFknxs13QgUjrhv92Jw@mail.gmail.com>
Date:   Thu, 19 Jul 2018 10:50:17 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Eran Ben Elisha <eranlinuxmellanox@...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 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.

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?)

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?

Or.