> > -----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-
> > l...@lists.osuosl.org
> > Cc: nhor...@redhat.com; jogre...@redhat.com; Linux Netdev List; Choi,
> > Sy Jong; Rony Efraim; David Miller; Edward Cree; Or Gerlitz;
> > sassm...@redhat.com
> > Subject: RE: [PATCH v5 3/3] ixgbe: Add new ndo to trust VF
> >
> >
> > > -----Original Message-----
> > > From: Hiroshi Shimamoto [mailto:h-shimam...@ct.jp.nec.com]
> > > Sent: Tuesday, May 26, 2015 5:28 PM
> > > To: Rose, Gregory V; Skidmore, Donald C; Kirsher, Jeffrey T;
> > > intel-wired- l...@lists.osuosl.org
> > > Cc: nhor...@redhat.com; jogre...@redhat.com; Linux Netdev List; Choi,
> > > Sy Jong; Rony Efraim; David Miller; Edward Cree; Or Gerlitz;
> > > sassm...@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- l...@lists.osuosl.org
> > > > > Cc: nhor...@redhat.com; jogre...@redhat.com; Linux Netdev List;
> > > > > Choi, Sy Jong; Rony Efraim; David Miller; Edward Cree; Or Gerlitz;
> > > > > sassm...@redhat.com
> > > > > Subject: RE: [PATCH v5 3/3] ixgbe: Add new ndo to trust VF
> > > > >
> > > > >
> > > >
> > > > [snip]
> > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Hiroshi Shimamoto [mailto:h-shimam...@ct.jp.nec.com]
> > > > > > Sent: Monday, May 25, 2015 6:00 PM
> > > > > > To: Skidmore, Donald C; Rose, Gregory V; Kirsher, Jeffrey T;
> > > > > > intel-wired- l...@lists.osuosl.org
> > > > > > Cc: nhor...@redhat.com; jogre...@redhat.com; Linux Netdev List;
> > > > > > Choi, Sy Jong; Rony Efraim; David Miller; Edward Cree; Or
> > > > > > Gerlitz; sassm...@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
N�����r��y����b�X��ǧv�^�){.n�+���z�^�)����w* jg��� �����ݢj/���z�ޖ��2�ޙ����&�)ߡ�a���� �G���h��j:+v���w��٥
