Re: [PATCH net-next] bonding: Support for multi function NIC devices

[Jay Vosburgh <fubar@us.ibm.com>]

Anirban Chakraborty <anirban.chakraborty@qlogic.com> wrote:
>On 7/15/12 9:39 PM, "John Fastabend" <john.r.fastabend@intel.com> wrote:
[...]
>>Also I'm not sure we need to explicitly block this.  It is clear from
>>looking at 'ip' output what the topology is. And in the SR-IOV
>>case would this still work if the functions are direct assigned? How
>>about if I try to bond two stacked devices that are on the same
>>physical link. In both case iirc the bus info wont match up.
>>
>>Seems easier to just call this a configuration error or not if for
>>some reason this is really what someone intended.
>>
>>.John
>
>I agree that for SR-IOV case with VFs assigned directly to the guest, bus
>info won't
>match up. However, I was thinking from the point of view of NIC
>partitioned mode (NPAR),
>and for the use case of SR-IOV VFs assigned to the hypervisor. It would be
>nice to
>prevent the user from getting into misconfiguration.

	If I'm understanding correctly, to hit the case you're worried
about here would require assigning multiple VFs from one PF to the same
linux instance as the PF itself, and then bonding those VFs together.

	Heck, there might be some arcane reason that somebody wants to
do that on purpose, or the test may inadvertently prohibit legal
configurations that happen to match the criteria.

	Has this been a real problem in practice?  I'm not seeing a
compelling argument for doing this.

	-J

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