On Fri, 14 Sep 2018 12:10:45 +0300 Or wrote: > On Fri, Sep 14, 2018 at 1:31 AM, Jesse Brandeburg > <jesse.brandeb...@intel.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. > > 41 files changed, 3436 insertions(+), 7581 deletions(-) > > code diet is cool! Thanks! ~4000 lines less made me very happy too.
