netdev - RE: [PATCH net-next] net: Add phys_port identifier to struct net

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <E31FB011129F30488D5861F383904915210BC0481A@BLRX7MCDC201.AMER.DELL.COM>
Date:	Tue, 25 Jun 2013 10:33:31 -0700
From:	<Narendra_K@...l.com>
To:	<john.fastabend@...il.com>
CC:	<bhutchings@...arflare.com>, <netdev@...r.kernel.org>,
	<john.r.fastabend@...el.com>
Subject: RE: [PATCH net-next] net: Add phys_port identifier to struct
 net_device and export it to sysfs

> -----Original Message-----
> From: John Fastabend [mailto:john.fastabend@...il.com]
> Sent: Friday, June 21, 2013 10:41 PM
> To: K, Narendra
> Cc: Ben Hutchings; netdev@...r.kernel.org; john.r.fastabend@...el.com
> Subject: Re: [PATCH net-next] net: Add phys_port identifier to struct
> net_device and export it to sysfs
> 
> On 06/19/2013 12:34 PM, Ben Hutchings wrote:
[...]

> > I think so.
> >
> >> If correct,  I think the 'show_broadcast' function also needs to be
> >> fixed as it is not holding the lock.
> >
> > I think the broadcast address should never change during the lifetime
> > of a device, so it doesn't need the lock.  That might not be true for
> > all layer 2 protocols though.
> >
> > Ben.
> >
> 
> Also, do you think this will be primarily useful for partitioning devices that
> expose multiple physical functions? Or do you see a use case for SR-IOV with
> virtual functions as well. The pyhs_port attribute provides a common
> interface for both cases which is good I suppose in the VF case however the
> host can already learn this. I gather from your original post here that you are
> aware of all this.
> 

John,   I think it will be useful in the SRIOV scenario also when more than one VF from two NICs are assigned to the guest. phys_port would be helpful in choosing the correct slave interfaces when host details are not available.
 
With regards,
Narendra K
Linux Engineering
Dell Inc.