netdev - Re: [E1000-devel] discussion questions: SR-IOV, virtualization, and bonding

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]

Date:	Thu, 02 Aug 2012 16:01:31 -0700
From:	Jay Vosburgh <fubar@...ibm.com>
To:	Chris Friesen <chris.friesen@...band.com>
cc:	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>,
	netdev <netdev@...r.kernel.org>
Subject: Re: [E1000-devel] discussion questions: SR-IOV, virtualization, and bonding

Chris Friesen <chris.friesen@...band.com> wrote:

>On 08/02/2012 04:26 PM, Chris Friesen wrote:
>> On 08/02/2012 02:30 PM, Jay Vosburgh wrote:
>
>>> The best long term solution is to have a user space API that
>>> provides link state input to bonding on a per-slave basis, and then some
>>> user space entity can perform whatever link monitoring method is
>>> appropriate (e.g., LLDP) and pass the results to bonding.
>>
>> I think this has potential. This requires a virtual communication
>> channel between guest/host if we want the host to be able to influence
>> the guest's choice of active link, but I think that's not unreasonable.

	Not necessarily, if something like LLDP runs across the virtual
link between the guest and slave, then the guest will notice when the
link goes down (although perhaps not very quickly).  I'm pretty sure the
infrastructure to make LLDP work on inactive slaves is already there; as
I recall, the "no wildcard" or "deliver exact" business in the receive
path is at least partially for LLDP.

	Still, though, isn't "influence the guest's choice" pretty much
satisified by having the VF interface go carrier down in the guest when
the host wants it to?  Or are you thinking about more fine grained than
that?

>> Actually, couldn't we do this now? Turn off miimon and arpmon, then just
>> have the userspace thing write to /sys/class/net/bondX/bonding/active_slave

	That might work for active-backup mode, yes, although it may not
handle the case when all slaves have failed if "failed" does not include
the slave being carrier down.  It's not quite the same thing as input to
the link monitoring logic.

>Hmm...looks like the bonding code requires either miimon or arpmon.  I
>wonder if setting miimon to INT_MAX might work, at least for some bonding
>modes.

	Not true; it's legal to leave miimon and arp_interval set to 0.
Older versions of bonding will whine about it, but let you do it; in
mainline, it's a debug message you have to choose to turn on (because
current versions of initscripts, et al, create the bond first, and then
set those options, so it tended to whine all the time).

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@...ibm.com

--
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