Re: [PATCH] ip_frag: replace the rte memcpy with memcpy

[Liang Ma <liangma@liangbit.com>]

On Fri, Jun 24, 2022 at 06:25:10PM +0100, Konstantin Ananyev wrote:
> 23/06/2022 03:35, Stephen Hemminger пишет:
> > On Wed, 22 Jun 2022 23:49:39 +0100
> > Konstantin Ananyev <konstantin.v.ananyev@yandex.ru> wrote:
> > 
> > > > @@ -26,7 +25,7 @@ static inline void __fill_ipv4hdr_frag(struct rte_ipv4_hdr *dst,
> > > >    		const struct rte_ipv4_hdr *src, uint16_t header_len,
> > > >    		uint16_t len, uint16_t fofs, uint16_t dofs, uint32_t mf)
> > > >    {
> > > > -	rte_memcpy(dst, src, header_len);
> > > > +	memcpy(dst, src, header_len);
> > > 
> > > 
> > > I am fine with replacements in test and inside the lib, for cases
> > > where 'len' parameter is constant value.
> > > Though as I said before, here 'header_len' is not a constant value.
> > > Are you sure it will not introduce any performance regression?
> > 
> > Do you have any performance tests. The ip header options are very small.
> 
> 
> From my experience - usually it is not about how big or small amount
> we need to copy. It is about can compiler evaluate 'size' parameter
> for memcpy() at compilation time or not.
> If it can, great - it will most likely replace memcpy()
> with some really well optimized code.
> If not it has to generate a proper call to actual
> memcpy() function. Which again, can be well optimized, but the
> overhead of the function call itself can still be noticeable,
> specially for small copies.
> Anyway, as I can see, David already integrated these changes anyway.
> So now, we'll have to wait and see would anyone complain or not.
> About performance testing, the only one I am aware about:
> examples/ip_fragmentation
> 
> Konstantin
> 
> 
For some small(<1k) size, " rep movsb" is very fast. much faster than I
expected. I just noticed this in another application.