On Wed, Sep 21, 2016 at 7:59 PM, Samudrala, Sridhar <sridhar.samudr...@intel.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.
