[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKOOJTzF=O+pdy=ZQ=hezjHjk7CKsBYiHg82pzGMA8UhCCRT4A@mail.gmail.com>
Date: Mon, 18 Jan 2021 09:37:24 -0800
From: Edwin Peer <edwin.peer@...adcom.com>
To: Michal Kubecek <mkubecek@...e.cz>
Cc: netdev <netdev@...r.kernel.org>, Jakub Kicinski <kuba@...nel.org>,
Stephen Hemminger <stephen@...workplumber.org>,
Andrew Gospodarek <andrew.gospodarek@...adcom.com>,
Michael Chan <michael.chan@...adcom.com>
Subject: Re: [PATCH iproute2] iplink: work around rtattr length limits for IFLA_VFINFO_LIST
On Sat, Jan 16, 2021 at 1:12 PM Michal Kubecek <mkubecek@...e.cz> wrote:
> My idea back then was to use a separate query which would allow getting
> VF information using a dump request (one VF per message); the reply for
> RTM_GETLINK request would either list all VFs as now if possible or only
> as many as fit into a nested attribute and indicate that the information
> is incomplete (or maybe omit the VF information in such case as
> usefulness of the truncated list is questionable).
Yip, that would probably be the right way to fix it if we can fix it
(falls into the 3rd approach mentioned in the patch).
> However, my take from the discussions was that most developers who took
> part rather thought that there is no need for such rtnetlink feature as
> there is a devlink interface which does not suffer from this limit and
> NICs with so many VFs that IFLA_VFINFO_LIST exceeds 65535 bytes can
> provide devlink interface to handle them.
Does that imply reworking ip link to use devlink interfaces as the fix?
Regards,
Edwin Peer
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4160 bytes)
Powered by blists - more mailing lists