[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1374439801.2804.90.camel@deadeye.wl.decadent.org.uk>
Date: Sun, 21 Jul 2013 21:50:01 +0100
From: Ben Hutchings <bhutchings@...arflare.com>
To: Or Gerlitz <or.gerlitz@...il.com>
CC: Jiri Pirko <jiri@...nulli.us>, <Narendra_K@...l.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
On Sun, 2013-07-21 at 23:29 +0300, Or Gerlitz wrote:
> On Sun, Jul 21, 2013 at 5:48 PM, Ben Hutchings
> <bhutchings@...arflare.com> wrote:
> > On Sun, 2013-07-21 at 14:14 +0300, Or Gerlitz wrote:
> >> On Sun, Jul 21, 2013 at 10:24 AM, Jiri Pirko <jiri@...nulli.us> wrote:
> >> [...]
> >>
> >> Sorry, I missed that fact that initially you responded on this thread
> >>
> >> > The value could be anything. But note that you have to have different
> >> > values for card1-port1,2 and card2-port1,2
> >>
> >> why?
> >
> > The intent is to identify physical ports uniquely, so userland can tell
> > whether two devices are backed by the same physical port.
>
> OK this makes sense, and I understand that there are also some SRIOV
> aspects / use cases where this field could be usefu, still I don't
> understamd the direct relation to virtual functions, as mentioned in
> the 1st patch.
Well the motivating problem was that a guest can't tell which VFs
connect to which ports or whether it has multiple VFs connected to the
same port. The host can already see work out that they're associated
based on PCIe config and topology.
This can also apply to PFs if you pass them through to guests, or if you
have multiple PFs connected to the same port, but that's rather less
common.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists