On Wed, 2016-09-21 at 22:21 +0300, Or Gerlitz wrote: > 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.
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.
signature.asc
Description: This is a digitally signed message part
