netdev - RE: [net-next-2.6 PATCH 1/2] Add ndo_set_vf_port

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: <43F901BD926A4E43B106BF17856F0755A3BE8B8F@orsmsx508.amr.corp.intel.com>
Date:	Mon, 26 Apr 2010 15:38:57 -0700
From:	"Rose, Gregory V" <gregory.v.rose@...el.com>
To:	Scott Feldman <scofeldm@...co.com>,
	David Miller <davem@...emloft.net>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"chrisw@...hat.com" <chrisw@...hat.com>,
	"arnd@...db.de" <arnd@...db.de>,
	"Williams, Mitch A" <mitch.a.williams@...el.com>
Subject: RE: [net-next-2.6 PATCH 1/2] Add ndo_set_vf_port_profile

>-----Original Message-----
>From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org]
>On Behalf Of Scott Feldman
>Sent: Monday, April 26, 2010 12:57 PM
>To: Scott Feldman; David Miller
>Cc: netdev@...r.kernel.org; chrisw@...hat.com; arnd@...db.de
>Subject: Re: [net-next-2.6 PATCH 1/2] Add ndo_set_vf_port_profile
>
>On 4/26/10 12:27 PM, "Scott Feldman" <scofeldm@...co.com> wrote:
>> We'd need an array of struct ifla_vf_port_profile hanging off of
>netdev, one
>> element for each VF.  That seems like a lot of mem hanging off of
>netdev,
>> and we'd have to define a MAX_VF to size the array.  How about a
>> ndo_get_vf_port_profile() that the netdev fills in, and the netdev
>keeps the
>> data in it's private area?  That's how ndo_get_vf_config() is working.
>
>Hmmm....even that isn't so nice because the port-profile info for all
>VFs is
>going to get stuffed into the RTM_GETLINK skb, and I assume there are
>limits
>on the skb return size.
>
>Here's a proposal:
>
>Currently we have RTM_GETLINK for
>
>    ip link show [ DEVICE ]
>
>This dumps everything for the DEVICE including info for each VF.  Let's
>modify RTM_GETLINK to look like this:
>
>    ip link show [ DEVICE [ vf NUM] ]
>
>If you don't give the optional vf NUM you get base dump on DEVICE.  If
>you
>give vf NUM, you get the VF-specific dump.  This scales much better with
>the
>number of VFs.
>
>(Number of VFs can easily be > 128 in some designs).
>
>Comments?

It seems to me that this:

ip link show [ DEVICE ]

should at least return the number of VFs so
that you can make sure the subsequent usage of this:

ip link show [ DEVICE [ vf NUM ] ]

is still in range with the [ vf NUM ] parameter.  Otherwise you wouldn't know
what the range of NUM is.

Other than that I can see why you would want to limit the size of the dump
when using 'ip link show [ DEVICE ]'.

- Greg

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