On Wed, 2020-07-15 at 11:03 -0700, Jakub Kicinski wrote: > On Wed, 15 Jul 2020 01:17:26 +0000 Wang, Haiyue wrote: > > > Could you say a little more about the application and motivation > > > for > > > this? > > > > Sure, I will try to describe the whole story. > > > > > We are talking about a single control domain here, correct? > > > > Correct. > > We have a long standing policy of not supporting or helping > bifurcated > drivers.
Jakub, From what I understand, a bifurcated driver carves out the host interface netdev's queues (resources if you want to further generalize this) and allows another entity to control/use them. If this is the definition, then DCF is not bifurcating the driver. DCF is on top of SR-IOV VFs and the device resources required for the DCF VF are made available by the device through the PCI configuration space during SR-IOV init. This part isn't anything different from the usual SR-IOV VF instantiation. The DCF feature adds the ability for a trusted VF to add flow rules. So this is really just an extension of the VF-PF interface that allows advanced flow/switch rules programming. Additionally, the driver also has a list of operations that the DCF VF is allowed to execute. Can you please clarify how you (and the community) define bifurcated driver? Thanks, Ani
