netdev - Re: [net-next 01/15] i40e: Introduce VF port representor/control netdevs

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: <CAJ3xEMj-teLmjg+Nzn0pHsnz8P=EY6uF4VzDJsxVEOTihStrLw@mail.gmail.com>
Date:   Wed, 21 Sep 2016 22:21:18 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
Cc:     Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        David Miller <davem@...emloft.net>,
        Linux Netdev List <netdev@...r.kernel.org>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "sassmann@...hat.com" <sassmann@...hat.com>,
        "jogreene@...hat.com" <jogreene@...hat.com>,
        guru.anbalagane@...cle.com, Ilya Lesokhin <ilyal@...lanox.com>,
        Andy Gospodarek <andy@...yhouse.net>,
        John Fastabend <john.r.fastabend@...el.com>,
        Jiri Pirko <jiri@...lanox.com>,
        Rony Efraim <ronye@...lanox.com>
Subject: Re: [net-next 01/15] i40e: Introduce VF port representor/control netdevs

On Wed, Sep 21, 2016 at 7:59 PM, Samudrala, Sridhar
<sridhar.samudrala@...el.com> wrote:
> On 9/21/2016 12:04 AM, Or Gerlitz wrote:

>> so what happens after this patchset is applied and before the future work is
>> submitted? RX/TX slow path through the VFPRs isn't supported and what
>> about fast path? in other words what happens when someone
>> loads the driver, sets SRIOV (--> the driver set itself to switchdev mode
>> and VFPRs are created) and then a VF sends a packet? do you still put
>> into the HW the legacy DMAC based switching rules? I am not following...

> The VF driver requests adding the dmac based filter rules via mailbox
> messages to PF and that is not changed in this patchset.
> Once we have VFPR TX/RX support, we will not allow the VF driver to add
> these rules, Instead a host based
> program will be able to add these rules to enable the fast path.

I see, this means that when this patch set is applied your driver
reports through devlink that they are in switchdev mode, but the
operational state of the VFs and VFPRs isn't such - as the VFs dictate
the steering and the VFPRs don't support slow path TX/RX --- in an
earlier comment you made on this thread you said that you will be
submitting RX/TX support in the next patchset. Maybe it would be best
if you can take the VFPRs patches out of this series and roll a follow
up series with all what's needed? unless you need more time and gonna
miss 4.9 as of that... if the patches are ready, I say lets have them
all in one series, if not, I wonder what other people think on the
matter. I am basically half+ good to have also the half baked code
base merged

Anyway, there's no point to report through ethtool something (VF vport
HW stats) you can report in the standard and convenient manner, so
this one please do address regardless of the prev comment.

Or.