IFLA_NUM_VF not set or improperly parsed

[Jef Oliver]

On 02/20/2014 10:41 AM, Jef Oliver wrote:
> On 02/20/2014 07:03 AM, Thomas Graf wrote:
>> On 02/13/14 at 04:20pm, Jef Oliver wrote:
>>> Hello,
>>> 
>>> On a system with SRIOV support and functional VFs (ixgbe) loaded (2
>>> per port), I get -NLE_OPNOTSUPP when calling rtnl_link_get_num_vf on
>>> any link with SRIOV support and VFs loaded. I am able to list the
>>> VFs with ip link show. I was digging through the code and got as far
>>> as IFLA_NUM_VF being parsed in the returned packet. This gets a bit
>>> deeper than my current netlink knowledge, so I am unsure where to
>>> move to next.
>>> 
>>> I have reproduced this in RHEL 6.4/6.5 with stock 2.6.32 inbox and
>>> updated 2.6.32 kernels, RHEL 6.5 with upstream 3.11.x and 3.12.x, as
>>> well as on an Arch Linux system running 3.12.x.
>>> 
>>> I am perfectly willing to dig deeper and figure out what is going on
>>> with a bit of guidance, or assist in any way I can.
>> 
>> The issue is that libnl does not yet provide the IFLA_EXT_MASK
>> attribute with a value of RTEXT_FILTER_VF when sending RTM_GETLINK
>> which is required to trigger sending of VF information in the kernel.
>> 
>> rtnl_link_build_get_request() must be extended with something
>> like:
>> 
>>         NLA_PUT_U32(msg, IFLA_EXT_MASK, RTEXT_FILTER_VF);
>> 
> 
> Thank you Thomas. I am exploring this.
> 
> Jef Oliver

I have this patched and working per your suggestion, and the definition 
of RTEXT_FILTER_VF. I want to make sure that 
rtnl_link_build_get_request() is the right area to do this in. Patching 
here allows rtnl_link_get_kernel() to properly report VFs on the system. 
However, it does not allow for cache operations to see that there are 
VFs. I'd imagine that being able to do this in cache operations is 
useful in some way, but I could be wrong.

Jef Oliver