[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iLcOE7aJ6SSjCSixLOQd4CsMdmE1UQZWBsp6UgufA2pwQ@mail.gmail.com>
Date: Fri, 1 Mar 2024 17:24:07 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Jakub Kicinski <kuba@...nel.org>, davem@...emloft.net, netdev@...r.kernel.org,
pabeni@...hat.com, vadim.fedorenko@...ux.dev, arkadiusz.kubalewski@...el.com
Subject: Re: [PATCH net-next] dpll: avoid multiple function calls to dump
netdev info
On Fri, Mar 1, 2024 at 4:40 PM Jiri Pirko <jiri@...nulli.us> wrote:
>
> Fri, Mar 01, 2024 at 01:16:07AM CET, kuba@...nel.org wrote:
> >Due to compiler oddness and because struct dpll_pin is defined
> >in a private header we have to call into dpll code to get
> >the handle for the pin associated with a netdev.
> >Combine getting the pin pointer and getting the info into
> >a single function call by having the helpers take a netdev
> >pointer, rather than expecting a pin.
> >
> >The exports are note needed, networking core can't be a module.
> >
> >Signed-off-by: Jakub Kicinski <kuba@...nel.org>
>
> Reviewed-by: Jiri Pirko <jiri@...dia.com>
>
>
> >---
> >BTW is the empty nest if the netdev has no pin intentional?
>
> The user can tell if this is or is not supported by kernel easily.
This is a high cost for hosts with hundreds of devices :/
Was it the reason you did not want me to remove zero IFLA_MAP ?
Powered by blists - more mailing lists