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] [day] [month] [year] [list]

Date:   Wed, 21 Sep 2016 14:23:28 -0700
From:   Jeff Kirsher <jeffrey.t.kirsher@...el.com>
To:     Or Gerlitz <gerlitz.or@...il.com>,
        "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
Cc:     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, 2016-09-21 at 22:21 +0300, Or Gerlitz wrote:
> 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.

I will drop Sridhar's changes from this series for now, so that he can do
the re-work AND provide the additional patches he referred to earlier at a
later date.
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)