Re: [PATCH net-next v2] netdevice: define and allocate &net_device _properly_
From: Simon Horman
Date: Wed Jul 10 2024 - 03:27:18 EST
On Tue, Jul 09, 2024 at 01:19:44PM -0700, Breno Leitao wrote:
> On Tue, Jul 09, 2024 at 07:11:28PM +0100, Simon Horman wrote:
> > On Tue, Jul 09, 2024 at 05:54:25AM -0700, Breno Leitao wrote:
> > > From: Alexander Lobakin <aleksander.lobakin@xxxxxxxxx>
> > >
> > > In fact, this structure contains a flexible array at the end, but
> > > historically its size, alignment etc., is calculated manually.
> > > There are several instances of the structure embedded into other
> > > structures, but also there's ongoing effort to remove them and we
> > > could in the meantime declare &net_device properly.
> > > Declare the array explicitly, use struct_size() and store the array
> > > size inside the structure, so that __counted_by() can be applied.
> > > Don't use PTR_ALIGN(), as SLUB itself tries its best to ensure the
> > > allocated buffer is aligned to what the user expects.
> > > Also, change its alignment from %NETDEV_ALIGN to the cacheline size
> > > as per several suggestions on the netdev ML.
> > >
> > > bloat-o-meter for vmlinux:
> > >
> > > free_netdev 445 440 -5
> > > netdev_freemem 24 - -24
> > > alloc_netdev_mqs 1481 1450 -31
> > >
> > > On x86_64 with several NICs of different vendors, I was never able to
> > > get a &net_device pointer not aligned to the cacheline size after the
> > > change.
> > >
> > > Signed-off-by: Alexander Lobakin <aleksander.lobakin@xxxxxxxxx>
> > > Signed-off-by: Breno Leitao <leitao@xxxxxxxxxx>
> > > Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@xxxxxxxxx>
> >
> > Hi Breno,
> >
> > Some kernel doc warnings from my side.
>
> Thanks. I will send a v3 with the fixes.
>
> > Flagged by: kernel-doc -none
>
> How do you run this test exactly? I would like to add to my workflow.
It can be run like this:
./scripts/kernel-doc -none include/linux/netdevice.h
Or this:
./scripts/kernel-doc -none -Wall include/linux/netdevice.h
In this case the second invocation has a lot of output relating
to documentation of return values which is unrelated to your patch.
But the first invocation shows the issues that I flagged in my previous
email.