[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs





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:
>> 
>>> On 03/01/2012 04:02 AM, Roopa Prabhu 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
>>> 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. 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]