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

Powered by blists - more mailing lists