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

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] [day] [month] [year] [list]

Date:	Sun, 15 Jul 2012 23:10:42 -0700
From:	Anirban Chakraborty <anirban.chakraborty@...gic.com>
To:	Jay Vosburgh <fubar@...ibm.com>
CC:	John Fastabend <john.r.fastabend@...el.com>,
	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	Dept-NX Linux NIC Driver 
	<Dept_NX_Linux_NIC_Driver@...gic.com>
Subject: Re: [PATCH net-next] bonding: Support for multi function NIC devices



On 7/15/12 10:50 PM, "Jay Vosburgh" <fubar@...ibm.com> wrote:

>Anirban Chakraborty <anirban.chakraborty@...gic.com> wrote:
>>On 7/15/12 9:39 PM, "John Fastabend" <john.r.fastabend@...el.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

The real problem that we have faced so far is the case of NPAR, where
multiple
physical functions are assigned to the linux host and the customer tried
to create
a bond of interfaces from the same physical port. In this case, linux host
was running
without any guest OS and the NICs are used for carrying host traffic only.

-Anirban


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