All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Skidmore, Donald C" <donald.c.skidmore@intel.com>
To: "Rose, Gregory V" <gregory.v.rose@intel.com>,
	Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
	"intel-wired-lan@lists.osuosl.org"
	<intel-wired-lan@lists.osuosl.org>
Cc: "nhorman@redhat.com" <nhorman@redhat.com>,
	"jogreene@redhat.com" <jogreene@redhat.com>,
	Linux Netdev List <netdev@vger.kernel.org>,
	"Choi, Sy Jong" <sy.jong.choi@intel.com>,
	Rony Efraim <ronye@mellanox.com>,
	"David Miller" <davem@davemloft.net>,
	Edward Cree <ecree@solarflare.com>,
	Or Gerlitz <gerlitz.or@gmail.com>,
	"sassmann@redhat.com" <sassmann@redhat.com>
Subject: RE: [PATCH v5 3/3] ixgbe: Add new ndo to trust VF
Date: Fri, 22 May 2015 17:51:51 +0000	[thread overview]
Message-ID: <F6FB0E698C9B3143BDF729DF22286646912FC2E3@ORSMSX110.amr.corp.intel.com> (raw)
In-Reply-To: <C5551D9AAB213A418B7FD5E4A6F30A07892F9481@ORSMSX108.amr.corp.intel.com>



> -----Original Message-----
> From: Rose, Gregory V
> Sent: Friday, May 22, 2015 8:08 AM
> 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: Intel-wired-lan
> > [mailto:intel-wired-lan-bounces@lists.osuosl.org] On Behalf Of Hiroshi
> > Shimamoto
> > Sent: Thursday, May 21, 2015 7:31 PM
> > To: 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: [Intel-wired-lan] [PATCH v5 3/3] ixgbe: Add new ndo to
> > trust VF
> >
> 
> [big snip]
> 
> > I think your concerns are related to some operational assumptions.
> > My basic concept is, not to change the behavior of VM, existing user
> > operation.
> > I mean that I didn't think it's better that the user should check the
> > both of the ixgbevf driver can deal with new API and the VF is trusted.
> >
> > Now, I think the point is who takes care whether the VF is trusted. Right?
> > It seems that you think the VF user should handle that user is trusted
> > and do something with a notice that "you're trusted or untrusted" from
> > the host.
> > Is that correct?
> > I made it in PF side, because it looks easy to handle it. If something
> > to do in VF side, I think ixgbevf driver should handle it.
> 
> Setting the VF trusted mode feature should only be allowed through the PF
> as it is the only trusted entity from the start.  We do not want the VF being
> able to decide for itself to be trusted.
> 
> - Greg
> 

I completely agree with Greg and never meant to imply anything else.

The PF should be where a given VF is made "trusted".  Likewise a VF can get promoted to MC Promiscuous buy requesting over 30 MC groups.  I like this and your patch currently does this.  So for example below:

PF					VF
----------				-----------
Set given VF as trusted
					Request 30+ MC groups via Mail Box
Put PF in MC Promiscuous mode


What I am concerned about is the following flow where we seem to store the fact the VF requests more than 30+ MC groups so that we can automatically enter MC Promisc Mode if that VF is ever made trusted. 

PF					VF
-----------				----------
Currently VF is NOT trusted
					Request 30+ MC groups via Mail Box
Do NOT put PF in MC Promisc
(hw->mac.mc_promisc = true)

< Some time later >

Set given VF as trusted
(because mc_promisc set) Put PF in MC Promisc


I don't like the fact that the PF remembers that the VF was denied MC Promiscuous mode in the past.  And because of that automatically put the VF in MC Promiscuous mode when it becomes trusted.  Maybe showing in code what I would like removed/added would be more helpful, probably should have started doing that. :)

I would remove this bit of code from ixgbe_ndo_set_vf_trust():

int ixgbe_ndo_set_vf_trust(struct net_device *netdev, int vf, bool 
setting) {
	struct ixgbe_adapter *adapter = netdev_priv(netdev);

	if (vf >= adapter->num_vfs)
		return -EINVAL;

	/* nothing to do */
	if (adapter->vfinfo[vf].trusted == setting)
		return 0;

	adapter->vfinfo[vf].trusted = setting;

-	/* Reconfigure features which are only allowed for trusted VF */
-	/* VF multicast promiscuous mode */
-	if (adapter->vfinfo[vf].mc_promisc)
-		ixgbe_enable_vf_mc_promisc(adapter, vf);

	return 0;
}

This of course would be we should not set mc_promisc ever if we are NOT trusted (adapter->vfinfo[vf].trusted) so in ixgbe_set_vf_mc_promisc() I would add or something like it:

static int ixgbe_set_vf_mc_promisc(struct ixgbe_adapter *adapter,
				   u32 *msgbuf, u32 vf)
{
	bool enable = !!msgbuf[1];	/* msgbuf contains the flag to enable */

	switch (adapter->vfinfo[vf].vf_api) {
	case ixgbe_mbox_api_12:
		break;
	default:
		return -1;
	}

+	/* have to be trusted */
+	If (!adapter->vfinfo[vf].trusted)
+		Return 0;
+
	/* nothing to do */
	if (adapter->vfinfo[vf].mc_promisc == enable)
		return 0;

	adapter->vfinfo[vf].mc_promisc = enable;

	if (enable)
		return ixgbe_enable_vf_mc_promisc(adapter, vf);
	else
		return ixgbe_disable_vf_mc_promisc(adapter, vf); }


Does this better explain what my concern is?

Thanks,
-Don Skidmore <donald.c.skidmore@intel.com>

WARNING: multiple messages have this Message-ID (diff)
From: Skidmore, Donald C <donald.c.skidmore@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH v5 3/3] ixgbe: Add new ndo to trust VF
Date: Fri, 22 May 2015 17:51:51 +0000	[thread overview]
Message-ID: <F6FB0E698C9B3143BDF729DF22286646912FC2E3@ORSMSX110.amr.corp.intel.com> (raw)
In-Reply-To: <C5551D9AAB213A418B7FD5E4A6F30A07892F9481@ORSMSX108.amr.corp.intel.com>



> -----Original Message-----
> From: Rose, Gregory V
> Sent: Friday, May 22, 2015 8:08 AM
> To: Hiroshi Shimamoto; Skidmore, Donald C; Kirsher, Jeffrey T; intel-wired-
> lan at lists.osuosl.org
> Cc: nhorman at redhat.com; jogreene at redhat.com; Linux Netdev List; Choi,
> Sy Jong; Rony Efraim; David Miller; Edward Cree; Or Gerlitz;
> sassmann at redhat.com
> Subject: RE: [PATCH v5 3/3] ixgbe: Add new ndo to trust VF
> 
> 
> > -----Original Message-----
> > From: Intel-wired-lan
> > [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Hiroshi
> > Shimamoto
> > Sent: Thursday, May 21, 2015 7:31 PM
> > To: Skidmore, Donald C; Kirsher, Jeffrey T; intel-wired-
> > lan at lists.osuosl.org
> > Cc: nhorman at redhat.com; jogreene at redhat.com; Linux Netdev List; Choi,
> > Sy Jong; Rony Efraim; David Miller; Edward Cree; Or Gerlitz;
> > sassmann at redhat.com
> > Subject: Re: [Intel-wired-lan] [PATCH v5 3/3] ixgbe: Add new ndo to
> > trust VF
> >
> 
> [big snip]
> 
> > I think your concerns are related to some operational assumptions.
> > My basic concept is, not to change the behavior of VM, existing user
> > operation.
> > I mean that I didn't think it's better that the user should check the
> > both of the ixgbevf driver can deal with new API and the VF is trusted.
> >
> > Now, I think the point is who takes care whether the VF is trusted. Right?
> > It seems that you think the VF user should handle that user is trusted
> > and do something with a notice that "you're trusted or untrusted" from
> > the host.
> > Is that correct?
> > I made it in PF side, because it looks easy to handle it. If something
> > to do in VF side, I think ixgbevf driver should handle it.
> 
> Setting the VF trusted mode feature should only be allowed through the PF
> as it is the only trusted entity from the start.  We do not want the VF being
> able to decide for itself to be trusted.
> 
> - Greg
> 

I completely agree with Greg and never meant to imply anything else.

The PF should be where a given VF is made "trusted".  Likewise a VF can get promoted to MC Promiscuous buy requesting over 30 MC groups.  I like this and your patch currently does this.  So for example below:

PF					VF
----------				-----------
Set given VF as trusted
					Request 30+ MC groups via Mail Box
Put PF in MC Promiscuous mode


What I am concerned about is the following flow where we seem to store the fact the VF requests more than 30+ MC groups so that we can automatically enter MC Promisc Mode if that VF is ever made trusted. 

PF					VF
-----------				----------
Currently VF is NOT trusted
					Request 30+ MC groups via Mail Box
Do NOT put PF in MC Promisc
(hw->mac.mc_promisc = true)

< Some time later >

Set given VF as trusted
(because mc_promisc set) Put PF in MC Promisc


I don't like the fact that the PF remembers that the VF was denied MC Promiscuous mode in the past.  And because of that automatically put the VF in MC Promiscuous mode when it becomes trusted.  Maybe showing in code what I would like removed/added would be more helpful, probably should have started doing that. :)

I would remove this bit of code from ixgbe_ndo_set_vf_trust():

int ixgbe_ndo_set_vf_trust(struct net_device *netdev, int vf, bool 
setting) {
	struct ixgbe_adapter *adapter = netdev_priv(netdev);

	if (vf >= adapter->num_vfs)
		return -EINVAL;

	/* nothing to do */
	if (adapter->vfinfo[vf].trusted == setting)
		return 0;

	adapter->vfinfo[vf].trusted = setting;

-	/* Reconfigure features which are only allowed for trusted VF */
-	/* VF multicast promiscuous mode */
-	if (adapter->vfinfo[vf].mc_promisc)
-		ixgbe_enable_vf_mc_promisc(adapter, vf);

	return 0;
}

This of course would be we should not set mc_promisc ever if we are NOT trusted (adapter->vfinfo[vf].trusted) so in ixgbe_set_vf_mc_promisc() I would add or something like it:

static int ixgbe_set_vf_mc_promisc(struct ixgbe_adapter *adapter,
				   u32 *msgbuf, u32 vf)
{
	bool enable = !!msgbuf[1];	/* msgbuf contains the flag to enable */

	switch (adapter->vfinfo[vf].vf_api) {
	case ixgbe_mbox_api_12:
		break;
	default:
		return -1;
	}

+	/* have to be trusted */
+	If (!adapter->vfinfo[vf].trusted)
+		Return 0;
+
	/* nothing to do */
	if (adapter->vfinfo[vf].mc_promisc == enable)
		return 0;

	adapter->vfinfo[vf].mc_promisc = enable;

	if (enable)
		return ixgbe_enable_vf_mc_promisc(adapter, vf);
	else
		return ixgbe_disable_vf_mc_promisc(adapter, vf); }


Does this better explain what my concern is?

Thanks,
-Don Skidmore <donald.c.skidmore@intel.com>

  reply	other threads:[~2015-05-22 17:51 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-20  0:06 [PATCH v5 3/3] ixgbe: Add new ndo to trust VF Hiroshi Shimamoto
2015-05-20  0:06 ` [Intel-wired-lan] " Hiroshi Shimamoto
2015-05-20 18:14 ` Skidmore, Donald C
2015-05-20 18:14   ` [Intel-wired-lan] " Skidmore, Donald C
2015-05-21  4:12   ` Hiroshi Shimamoto
2015-05-21  4:12     ` [Intel-wired-lan] " Hiroshi Shimamoto
2015-05-21 17:08     ` Skidmore, Donald C
2015-05-21 17:08       ` [Intel-wired-lan] " Skidmore, Donald C
2015-05-22  2:31       ` Hiroshi Shimamoto
2015-05-22  2:31         ` [Intel-wired-lan] " Hiroshi Shimamoto
2015-05-22 15:07         ` Rose, Gregory V
2015-05-22 15:07           ` [Intel-wired-lan] " Rose, Gregory V
2015-05-22 17:51           ` Skidmore, Donald C [this message]
2015-05-22 17:51             ` Skidmore, Donald C
2015-05-26  0:59             ` Hiroshi Shimamoto
2015-05-26  0:59               ` [Intel-wired-lan] " Hiroshi Shimamoto
2015-05-26 17:45               ` Skidmore, Donald C
2015-05-26 17:45                 ` [Intel-wired-lan] " Skidmore, Donald C
2015-05-26 18:03                 ` Rose, Gregory V
2015-05-26 18:03                   ` [Intel-wired-lan] " Rose, Gregory V
2015-05-27  0:27                   ` Hiroshi Shimamoto
2015-05-27  0:27                     ` [Intel-wired-lan] " Hiroshi Shimamoto
2015-05-27  2:00                     ` Rose, Gregory V
2015-05-27  2:00                       ` [Intel-wired-lan] " Rose, Gregory V
2015-05-27 16:00                       ` Skidmore, Donald C
2015-05-27 16:00                         ` [Intel-wired-lan] " Skidmore, Donald C
2015-05-27 16:19                         ` Rose, Gregory V
2015-05-27 16:19                           ` [Intel-wired-lan] " Rose, Gregory V
2015-06-15 10:39                         ` Hiroshi Shimamoto
2015-06-15 10:39                           ` [Intel-wired-lan] " Hiroshi Shimamoto
2015-05-27  9:03                     ` Edward Cree
2015-05-27  9:03                       ` [Intel-wired-lan] " Edward Cree
2015-05-27 15:34                       ` Skidmore, Donald C
2015-05-27 15:34                         ` [Intel-wired-lan] " Skidmore, Donald C
2015-05-27 15:55                         ` Rose, Gregory V
2015-05-27 15:55                           ` [Intel-wired-lan] " Rose, Gregory V
2015-05-27 17:04                           ` Edward Cree
2015-05-27 17:04                             ` [Intel-wired-lan] " Edward Cree

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F6FB0E698C9B3143BDF729DF22286646912FC2E3@ORSMSX110.amr.corp.intel.com \
    --to=donald.c.skidmore@intel.com \
    --cc=davem@davemloft.net \
    --cc=ecree@solarflare.com \
    --cc=gerlitz.or@gmail.com \
    --cc=gregory.v.rose@intel.com \
    --cc=h-shimamoto@ct.jp.nec.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jogreene@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@redhat.com \
    --cc=ronye@mellanox.com \
    --cc=sassmann@redhat.com \
    --cc=sy.jong.choi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.