Re: [PATCH net-next] bnx2x: Add Nic partitioning mode (57712 devices)

[Matt Domsch <Matt_Domsch@dell.com>]

On Mon, Nov 29, 2010 at 11:33:12AM +0200, Eilon Greenstein wrote:
> The main difference here is that we are talking about multiple PFs - so
> each can be brought up or down independently of the others. So there is
> no one master PF that controls the port and once it is brought down, the
> port is down too. At any given moment, one of the PFs is acting as the
> port master and controls the shared HW - but once this PF is brought
> down, another PF is seamlessly taking over.

Hmm, that complicates things a bit.
 
> I think the main difference is that we have real PCI functions and not
> virtual ones. On the same PCI bus, we have two physical ports, and 8
> physical functions - 4 on each port. I agree that exposing which
> functions are using the same port can really help - so I'm open to
> suggestions on the "how".

We really need, for NPAR, SR-IOV, and the Chelsio
multiple-ports-per-PCI-device model, a "network port" abstraction in
sysfs.  We need the ability to map M ports to N PCI devices, and
expose that mapping in sysfs.

For SR-IOV, biosdevname follows the physfn and virtfn* pointers to map
VFs to the PF.  But it assumes 1 PF -> 1 port.  For the Intel 1GbE and
10GbE cards I have, this is true, but nothing says it has to be true.

Maybe something like:

/sys/class/net_port/<port_name>/<ifname> -> /sys/class/net/<ifname>

/sys/class/net/<ifname>/port -> /sys/class/net_port/<port_name>

This introduces the idea of ports, though adds the complication of
needing to name them somehow.  But it would expose the relationship of
each net interface to a specific port, as well as allow multiple
interfaces per port, conceptually independent of the PCI device
mapping.  That way, each driver, which must know the mapping somehow,
could fill these links out?

-- 
Matt Domsch
Technology Strategist
Dell | Office of the CTO