On 3/1/12 7:52 AM, "Stefan Berger" <stefanb@linux.vnet.ibm.com> wrote:
On 03/01/2012 10:32 AM, Roopa Prabhu wrote:
On 3/1/12 4:39 AM, "Stefan Berger"<stefanb@linux.vnet.ibm.com> wrote:
From: Roopa Prabhu<roprabhu@cisco.com>
This patch includes the following changes - removes some netlink functions which are now available in virnetdev.c - Adds a vf argument to all port profile functions
For 802.1Qbh devices, the port profile calls can use a vf argument if passed by the caller. If the vf argument is -1 it will try to derive the vf if the device passed is a virtual function.
For 802.1Qbg devices, This patch introduces a null check for the device argument because during port profile assignment on a hostdev, this argument can be null. Stefan CC'ed for comments I agree to the change per se since entering the function with a NULL
On 03/01/2012 04:02 AM, Roopa Prabhu wrote: parameter would be fatal, though I am wondering under what condition this can occur. I don't see this happening in the Associate call path for example. It happens in patch 4/4 where we call associate for a hostdev and there is no macvtap available there.
So this hostdev related code can only be used by 802.1Qbh because the type of device does not exist for 802.1Qbg?
Not really. The hostdev device is just a pci device. But looking at 802.1Qbg port profile related code..i was not sure how it can be done when the device is a hostdev.
I think that at least there should be an error message logging the fact that the function was called without an interface name. Also the return error code should probably be -1 and not be overloaded with -E*. Ok This can be done.
If possible (unless already done) the combination of hostdev and 802.1Qbg should probably even be prevented on the XML level. This is not done yet. I think I will do it. And then if someone knows how to do it for 802.1Qbg they can open this up.
Thanks stefan.