On Thu, Jul 6, 2017 at 4:26 PM, Wyborny, Carolyn <carolyn.wybo...@intel.com> wrote: >> -----Original Message----- >> From: Greg Rose [mailto:gvrose8...@gmail.com] >> Sent: Thursday, July 06, 2017 7:25 AM >> To: Wyborny, Carolyn <carolyn.wybo...@intel.com> >> Cc: Stefan Assmann <sassm...@kpanic.de>; intel-wired-...@lists.osuosl.org; >> netdev@vger.kernel.org; da...@davemloft.net >> Subject: Re: [Intel-wired-lan] [PATCH 1/2] i40e/i40evf: rename >> vf_offload_flags to vf_cap_flags in struct virtchnl_vf_resource >> >> On Wed, Jul 5, 2017 at 10:15 PM, Wyborny, Carolyn >> <carolyn.wybo...@intel.com> wrote: >> > >> > > -----Original Message----- >> > > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On >> Behalf >> > > Of Stefan Assmann >> > > Sent: Thursday, June 29, 2017 6:12 AM >> > > To: intel-wired-...@lists.osuosl.org >> > > Cc: netdev@vger.kernel.org; da...@davemloft.net; >> sassm...@kpanic.de >> > > Subject: [Intel-wired-lan] [PATCH 1/2] i40e/i40evf: rename >> vf_offload_flags to >> > > vf_cap_flags in struct virtchnl_vf_resource >> > > >> > > The current name of vf_offload_flags indicates that the bitmap is >> > > limited to offload related features. Make this more generic by renaming >> > > it to vf_cap_flags, which allows for other capabilities besides >> > > offloading to be added. >> > > >> > > Signed-off-by: Stefan Assmann <sassm...@kpanic.de> >> > > --- >> > >> > Hello Stefan, >> > >> > Thanks for the patch series, but we believe the vf should be ignorant of >> > its >> trusted status. >> >> Hi Carolyn, >> >> Might I ask why? >> >> Thanks, >> >> - Greg > > Hello Greg, > > The trusted status of the vf is something that pf manages, mostly for > security reasons. The mailbox model of communication between them relies on > the pf to have authority over the vf. In most things, the vf asks permission > from the pf for changes in its configuration and this keeps the pf as the > gatekeeper between trusted and regular vf's. However, the issue here is that > changing the MAC address from within the vf does not go through the mailbox, > so it cannot tell if the vf is trusted or not. We are working on a redesign > of this feature to fix that instead of having the vf sort of know its > trusted. If, for some reason, we are unable to redesign it that way we would > reconsider this method instead. > > Thanks,
Thanks, that was my concern, that by allowing the VF to set it's own MAC then it would implicitly know it was trusted. Regards, - Greg > > Carolyn
