Re: [E1000-devel] [PATCH v2 2/3] if_link: Add VF multicast promiscuous control

2015-02-23 Thread Edward Cree
On 20/02/15 21:05, Skidmore, Donald C wrote:
 If a vender specific interface is objectionable maybe a simpler and more 
 generic interface would be for the PF to be able to set a given VF into 
 trusted mode... I admit exactly what 'trusted' meant would vary from vender 
 to vender, but it would be a way for the driver to know it could allow 
 configurations such as this.  Just an idea, since we seem to be getting more 
 requests for things such as this.
That's an even worse idea; now you have a generic interface with
completely undefined semantics.
The right way to do this, imho, is to use one of the standard interfaces
for driver-specific gubbins - e.g. sysfs, genetlink or even (whisper it)
ioctls - and put your 'VF promisc mode' setting there.  That way you
have a vendor-specific interface with vendor-specified semantics.
Of those options, I'd recommend sysfs as the best fit.
The information contained in this message is confidential and is intended for 
the addressee(s) only. If you have received this message in error, please 
notify the sender immediately and delete the message. Unless you are an 
addressee (or authorized to receive for an addressee), you may not use, copy or 
disclose to anyone this message or any information contained in this message. 
The unauthorized use, disclosure, copying or alteration of this message is 
strictly prohibited.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel#174; Ethernet, visit 
http://communities.intel.com/community/wired


Re: [E1000-devel] [PATCH v2 2/3] if_link: Add VF multicast promiscuous control

2015-02-23 Thread Skidmore, Donald C
 -Original Message-
 From: Edward Cree [mailto:ec...@solarflare.com]
 Sent: Monday, February 23, 2015 5:53 AM
 To: Skidmore, Donald C
 Cc: Hiroshi Shimamoto; vyase...@redhat.com; Kirsher, Jeffrey T; Alexander
 Duyck; Bjørn Mork; e1000-devel@lists.sourceforge.net;
 net...@vger.kernel.org; Choi, Sy Jong; linux-ker...@vger.kernel.org; David
 Laight; Hayato Momma
 Subject: Re: [PATCH v2 2/3] if_link: Add VF multicast promiscuous control
 
 On 20/02/15 21:05, Skidmore, Donald C wrote:
  If a vender specific interface is objectionable maybe a simpler and more
 generic interface would be for the PF to be able to set a given VF into
 trusted mode... I admit exactly what 'trusted' meant would vary from
 vender to vender, but it would be a way for the driver to know it could allow
 configurations such as this.  Just an idea, since we seem to be getting more
 requests for things such as this.
 That's an even worse idea; now you have a generic interface with completely
 undefined semantics.
 The right way to do this, imho, is to use one of the standard interfaces for
 driver-specific gubbins - e.g. sysfs, genetlink or even (whisper it) ioctls - 
 and
 put your 'VF promisc mode' setting there.  That way you have a vendor-
 specific interface with vendor-specified semantics.
 Of those options, I'd recommend sysfs as the best fit.
 The information contained in this message is confidential and is intended for
 the addressee(s) only. If you have received this message in error, please
 notify the sender immediately and delete the message. Unless you are an
 addressee (or authorized to receive for an addressee), you may not use,
 copy or disclose to anyone this message or any information contained in this
 message. The unauthorized use, disclosure, copying or alteration of this
 message is strictly prohibited.

I do see your point, but I thought custom sysfs interfaces (not to even mention 
new ioctl's :) were frowned upon?  Which is why I didn't even consider sysfs as 
an option.
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel#174; Ethernet, visit 
http://communities.intel.com/community/wired


Re: [E1000-devel] [PATCH net-next] i40e: mark constant as ULL

2015-02-23 Thread Stefan Assmann
On 04.02.2015 18:49, Jeff Kirsher wrote:
 On Wed, 2015-02-04 at 12:41 +0100, Stefan Assmann wrote:
 This avoids a compile error on 32bit.

 Signed-off-by: Stefan Assmann sassm...@kpanic.de
 ---
  drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 Come to find out, I already have a fix in my queue for this.  So I will
 be dropping your patch.
 
 The patch in my queue fixes the issue by doing the folling change:
 -   mask = 0x;
 +   mask = ~(u64)0;
 

Jeff,

this does not seem to compile on 32bit either. Please verify and if
you agree let's put my patch back in place instead of this one. IIRC
your patch has not been posted yet.

  Stefan

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel#174; Ethernet, visit 
http://communities.intel.com/community/wired


Re: [E1000-devel] [PATCH v2 2/3] if_link: Add VF multicast promiscuous control

2015-02-23 Thread Jeff Kirsher
On Mon, 2015-02-23 at 06:29 -0800, Skidmore, Donald C wrote:
  -Original Message-
  From: Edward Cree [mailto:ec...@solarflare.com]
  Sent: Monday, February 23, 2015 5:53 AM
  To: Skidmore, Donald C
  Cc: Hiroshi Shimamoto; vyase...@redhat.com; Kirsher, Jeffrey T; Alexander
  Duyck; Bjørn Mork; e1000-devel@lists.sourceforge.net;
  net...@vger.kernel.org; Choi, Sy Jong; linux-ker...@vger.kernel.org; David
  Laight; Hayato Momma
  Subject: Re: [PATCH v2 2/3] if_link: Add VF multicast promiscuous control
  
  On 20/02/15 21:05, Skidmore, Donald C wrote:
   If a vender specific interface is objectionable maybe a simpler and more
  generic interface would be for the PF to be able to set a given VF into
  trusted mode... I admit exactly what 'trusted' meant would vary from
  vender to vender, but it would be a way for the driver to know it could 
  allow
  configurations such as this.  Just an idea, since we seem to be getting more
  requests for things such as this.
  That's an even worse idea; now you have a generic interface with completely
  undefined semantics.
  The right way to do this, imho, is to use one of the standard interfaces for
  driver-specific gubbins - e.g. sysfs, genetlink or even (whisper it) ioctls 
  - and
  put your 'VF promisc mode' setting there.  That way you have a vendor-
  specific interface with vendor-specified semantics.
  Of those options, I'd recommend sysfs as the best fit.
  The information contained in this message is confidential and is intended 
  for
  the addressee(s) only. If you have received this message in error, please
  notify the sender immediately and delete the message. Unless you are an
  addressee (or authorized to receive for an addressee), you may not use,
  copy or disclose to anyone this message or any information contained in this
  message. The unauthorized use, disclosure, copying or alteration of this
  message is strictly prohibited.
 
 I do see your point, but I thought custom sysfs interfaces (not to even 
 mention new ioctl's :) were frowned upon?  Which is why I didn't even 
 consider sysfs as an option.

We discussed this during NetConf last week, and Don is correct that a
custom sysfs interface is not the way we want to handle this.  We agreed
upon a generic interface so that any NIC is able to turn on or off VF
multicast promiscuous mode.


signature.asc
Description: This is a digitally signed message part
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel#174; Ethernet, visit 
http://communities.intel.com/community/wired