RE: [PATCH v5 3/3] ixgbe: Add new ndo to trust VF

[Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>]

> > -----Original Message-----
> > From: Rose, Gregory V
> > Sent: Tuesday, May 26, 2015 7:01 PM
> > To: Hiroshi Shimamoto; Skidmore, Donald C; Kirsher, Jeffrey T; intel-wired-
> > lan@lists.osuosl.org
> > Cc: nhorman@redhat.com; jogreene@redhat.com; Linux Netdev List; Choi,
> > Sy Jong; Rony Efraim; David Miller; Edward Cree; Or Gerlitz;
> > sassmann@redhat.com
> > Subject: RE: [PATCH v5 3/3] ixgbe: Add new ndo to trust VF
> >
> >
> > > -----Original Message-----
> > > From: Hiroshi Shimamoto [mailto:h-shimamoto@ct.jp.nec.com]
> > > Sent: Tuesday, May 26, 2015 5:28 PM
> > > To: Rose, Gregory V; Skidmore, Donald C; Kirsher, Jeffrey T;
> > > intel-wired- lan@lists.osuosl.org
> > > Cc: nhorman@redhat.com; jogreene@redhat.com; Linux Netdev List; Choi,
> > > Sy Jong; Rony Efraim; David Miller; Edward Cree; Or Gerlitz;
> > > sassmann@redhat.com
> > > Subject: RE: [PATCH v5 3/3] ixgbe: Add new ndo to trust VF
> > >
> > > > > -----Original Message-----
> > > > > From: Skidmore, Donald C
> > > > > Sent: Tuesday, May 26, 2015 10:46 AM
> > > > > To: Hiroshi Shimamoto; Rose, Gregory V; Kirsher, Jeffrey T;
> > > > > intel-wired- lan@lists.osuosl.org
> > > > > Cc: nhorman@redhat.com; jogreene@redhat.com; Linux Netdev List;
> > > > > Choi, Sy Jong; Rony Efraim; David Miller; Edward Cree; Or Gerlitz;
> > > > > sassmann@redhat.com
> > > > > Subject: RE: [PATCH v5 3/3] ixgbe: Add new ndo to trust VF
> > > > >
> > > > >
> > > >
> > > > [snip]
> > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Hiroshi Shimamoto [mailto:h-shimamoto@ct.jp.nec.com]
> > > > > > Sent: Monday, May 25, 2015 6:00 PM
> > > > > > To: Skidmore, Donald C; Rose, Gregory V; Kirsher, Jeffrey T;
> > > > > > intel-wired- lan@lists.osuosl.org
> > > > > > Cc: nhorman@redhat.com; jogreene@redhat.com; Linux Netdev List;
> > > > > > Choi, Sy Jong; Rony Efraim; David Miller; Edward Cree; Or
> > > > > > Gerlitz; sassmann@redhat.com
> > > > > > Subject: RE: [PATCH v5 3/3] ixgbe: Add new ndo to trust VF
> > > > > >
> > > > > >
> > > > > > Do you mean that VF should care about it is trusted or not?
> > > > > > Should VF request MC Promisc again when it's trusted?
> > > > > > Or, do you mean VF never be trusted during its (or VM's) lifetime?
> > > > >
> > > > > I think the VF shouldn't directly know whether it is trusted or
> > > > > not
> > > >
> > > > That's completely irrevelant.  The person administering the PF will
> > > > be the person who provided trusted privileges to the VF.  He'll then
> > > > *tell* or somehow other communicate to the person administering the
> > > > VF
> > > (probably himself/herself) and then proceed to execute commands on
> > > that VF that require trusted privileges.
> > > >
> > > > If the VF does not have trusted privileges then the commands to add
> > > > VLAN filters, set promiscuous modes, and any other privileged
> > > > commands
> > > will fail.
> > > >
> > > > Let's not get too fancy with this.  It's simple - the host VMM admin
> > > > provides trusted privileges to the VF.  The person administering the
> > > > VF (if in fact it is not the same person, it usually will be) will
> > > proceed to do things that require VF trusted privileges.
> > >
> > > Now I think that it's better to have an interface between PF and VF to
> > > know the VF is trusted.
> > > Otherwise VM cannot know whether its VF is trusted, that prevents
> > > automatic operations.
> >
> > Agreed, it would be silly for the VF to have privileges but not know that it can
> > use them!
> >
> > > Or add another communicating interface outside of ixgbe PF-VF mbox API?
> >
> > We can't depend on any given vendor specific interface.  I'd add a very clear
> > comment in the Physical Function ndo op that gives a VF trusted privileges
> > that it is up to the driver to notify the VF driver.  But yes, in the case of Intel
> > drivers the mailbox or admin queue (for i40e) would be the mechanism to do
> > that.  I know you have some ixgbe patches that coincide with this patch so
> > that's a good place to look.
> >
> 
> Now why I am not against this (VF knowing it is "trusted") happening I don't see the need for it either.  I believe the
> same could be accomplished by allowing the PF to ask for whatever configuration it wants and some requests will not be
> granted by the PF unless the VF is trusted.  Given, this may require an extension of the mailbox messages to allow for
> NAK's to make it clear to the VF the request wasn't granted.
> 
> However like Greg mentions above this need not be requirement, different drivers could implement this way or not.
> 

Now I'm preparing a patchset to handle an error against VF MC promisc request.
I'm not sure that which is better to have new mailbox API which indicates VF is trusted.

I made a patchset which doesn't add new API but handles error against VF MC promisc request.
Will submit it.

thanks,
Hiroshi