netdev - Re: [RFC PATCH net-next v1 00/14] rename and shrink i40evf

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]

Message-ID: <CAJ3xEMi2HGS+rpEaEc-iuqbrswedKidox7QRNmdgURaoUUqmfw@mail.gmail.com>
Date:   Fri, 21 Sep 2018 16:51:56 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Jesse Brandeburg <jesse.brandeburg@...el.com>
Cc:     Linux Netdev List <netdev@...r.kernel.org>,
        intel-wired-lan <intel-wired-lan@...ts.osuosl.org>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        Saeed Mahameed <saeedm@...lanox.com>
Subject: Re: [RFC PATCH net-next v1 00/14] rename and shrink i40evf

On Fri, Sep 14, 2018 at 10:17 PM, Jesse Brandeburg
<jesse.brandeburg@...el.com> wrote:
> On Fri, 14 Sep 2018 12:10:45 +0300 Or wrote:
>> On Fri, Sep 14, 2018 at 1:31 AM, Jesse Brandeburg
>> <jesse.brandeburg@...el.com> wrote:
>> on what HW ring format do you standardize? do i40e/Fortville and
>> ice/what's-the-intel-code-name?  HWs can/use the same posting/completion
>> descriptor?
>
> The initial ring format is the same as used for XL710/X722 devices, and
> planned be supported for the Intel Ethernet E800 series (ice driver) and
> future VF devices using SR-IOV.
>
>> > This solves 2 issues we saw coming or were already present, the
>> > first was constant code duplication happening with i40e/i40evf,
>> > when much of the duplicate code in the i40evf was not used or was
>> > not needed.
>>
>> could you spare few words on the origin/nature of these duplicates? were them
>> just developer C&P mistakes for functionality which is irrelevant for
>> a VF? like what?
>> if not, what was there?
>
> In particular, some of the code was not used at all, but was not caught
> by any automation because it was in a header file and included into
> multiple file scopes.  Other big chunk of the duplicate code was for
> the PF's usage of the communication channel to firmware, which for some
> reason was left in the VF driver code (probably just to avoid changing
> the file) - but the VF driver doesn't communicate to firmware, just to
> the PF.
>
>> > The second was to remove the future confusion of why
>> > future VF devices that were not considered "40GbE" only devices
>> > were supported by i40evf.
>>
>> can elaborate further?
>
> The name i40evf was generating customer questions, and was confusing
> when you add in multiple generations of PF hardware that are no longer
> using the i40e driver.
>
>> > The thought is that iavf will be the virtual function driver for
>> > all future devices, so it should have a "generic" name to propery
>> > represent that it is the VF driver for multiple generations of
>> > devices.
>>
>> for that end,  as I think was explained @ the netdev Tokyo AVF session,
>> you would need a mechanism for feature negotiation, is it here or coming up?
>
> The driver already has it (a feature negotitiation), please see the
> function called iavf_send_vf_config_msg, and follow from where it is
> called.  Basically the VF driver negotiates with the PF for what it can
> do, and the PF guarantees that the base set of features will always
> work, with optional advanced features which the code may/may-not have
> in the future.

got it, same goes to the other replies below/above

>
>> >  41 files changed, 3436 insertions(+), 7581 deletions(-)
>>
>> code diet is cool!
>
> Thanks! ~4000 lines less made me very happy too.