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 <[email protected]>
> > > 
> > > 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 <[email protected]>
> > > Signed-off-by: Breno Leitao <[email protected]>
> > > Reviewed-by: Przemek Kitszel <[email protected]>
> > 
> > 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.



Reply via email to