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]

Date:   Thu, 19 Jul 2018 13:29:19 +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 12:02 PM, Eran Ben Elisha
<eranlinuxmellanox@...il.com> wrote:
> 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.

Do we know that all the flows in stack that deals with reception of packets do
this marking for encapsulated packets? is this documented some/where? if
this is what we think, then the patch is ok.