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]
Message-ID: <51CDBAE9.1020807@gmail.com>
Date:	Fri, 28 Jun 2013 09:33:45 -0700
From:	John Fastabend <john.fastabend@...il.com>
To:	Narendra_K@...l.com
CC:	bhutchings@...arflare.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

[...]

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

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

.John

-- 
John Fastabend         Intel Corporation
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ