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 for Android: free password hash cracker in your pocket

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

Message-ID: <1372439353.1937.21.camel@bwh-desktop.uk.level5networks.com>
Date:	Fri, 28 Jun 2013 18:09:13 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	John Fastabend <john.fastabend@...il.com>
CC:	<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 Fri, 2013-06-28 at 09:33 -0700, John Fastabend wrote:
> [...]
> 
> >>
> >> 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.
> 
> OK. But I'm not sure why you would assign two VFs from the same NIC
> to a guest? This doesn't seem like a good configuration for failover
> because if one VF fails it seems likely both will fail. Maybe there
> are some benefits for load balancing? Or my assumption both VFs will
> fail is wrong.

I believe Narendra is trying to provide hints to the guest that would
allow it to avoid such broken bonding configurations.  But it is
certainly a good question why there would be two VFs assigned in the
first place.

I could imagine passing through two VFs for the same physical port that
have been assigned to different VLANs.  But then you wouldn't want to
bond two devices that are on different VLANs, whether or not they're
using the same port!

> Anyways it does seem useful in the partitioning case with multiple
> physical functions.

I was thinking it could also help to support the hybrid guest networking
mode.  In this mode, the guest gets a PV (e.g. virtio_net) device and a
VF bridged to the same physical port, and the VF can be removed before
the guest is migrated (and maybe reinserted if there's a VF available on
the new host) without a major disruption to the guest.  In that case the
guest *should* bond together the two net devices that have the same
physical port ID but different drivers.  This would require the physical
port ID to be propagated through macvtap/macvlan and virtio.

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