Re: [PATCH v19 bpf-next 03/23] net: mvneta: update mb bit before passing the xdp buffer to eBPF layer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Lorenzo Bianconi wrote:
> > Lorenzo Bianconi wrote:
> > > Update multi-buffer bit (mb) in xdp_buff to notify XDP/eBPF layer and
> > > XDP remote drivers if this is a "non-linear" XDP buffer. Access
> > > skb_shared_info only if xdp_buff mb is set in order to avoid possible
> > > cache-misses.
> > > 
> > > Signed-off-by: Lorenzo Bianconi <lorenzo@xxxxxxxxxx>
> > 
> > [...]
> > 
> > > @@ -2320,8 +2325,12 @@ mvneta_swbm_build_skb(struct mvneta_port *pp, struct page_pool *pool,
> > >  		      struct xdp_buff *xdp, u32 desc_status)
> > >  {
> > >  	struct skb_shared_info *sinfo = xdp_get_shared_info_from_buff(xdp);
> > > -	int i, num_frags = sinfo->nr_frags;
> > >  	struct sk_buff *skb;
> > > +	u8 num_frags;
> > > +	int i;
> > > +
> > > +	if (unlikely(xdp_buff_is_mb(xdp)))
> > > +		num_frags = sinfo->nr_frags;
> > 
> > Doesn't really need a respin IMO, but rather an observation. Its not
> > obvious to me the unlikely/likely pair here is wanted. Seems it could
> > be relatively common for some applications sending jumbo frames.
> > 
> > Maybe worth some experimenting in the future.
> 
> Probably for mvneta it will not make any difference but in general I tried to
> avoid possible cache-misses here (accessing sinfo pointers). I will carry out
> some comparison to see if I can simplify the code.

Agree, I'll predict for mvneta it doesn't make a difference either way and
perhaps if you want to optimize small pkt benchmarks on a 100Gbps nic it would
show a win.



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux