lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 4 Jul 2019 16:06:35 +0300
From:   Ilias Apalodimas <>
To:     Jose Abreu <>
Cc:     Jesper Dangaard Brouer <>,
        "" <>,
        "" <>,
        Joao Pinto <>,
        "David S . Miller" <>,
        Giuseppe Cavallaro <>,
        Alexandre Torgue <>,
        Maxime Coquelin <>,
        Maxime Ripard <>,
        Chen-Yu Tsai <>
Subject: Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page

Hi Jose, 

> Thank you all for your review comments !
> From: Ilias Apalodimas <>
> > That's why i was concerned on what will happen on > 1000b frames and what the
> > memory pressure is going to be. 
> > The trade off here is copying vs mapping/unmapping.
> Well, the performance numbers I mentioned are for TSO with default MTU 
> (1500) and using iperf3 with zero-copy. Here follows netperf:

Ok i guess this should be fine. Here's why.
You'll allocate an extra memory from page pool API which equals
the number of descriptors * 1 page.
You also allocate SKB's to copy the data and recycle the page pool buffers.
So page_pool won't add any significant memory pressure since we expect *all*
it's buffers to be recycled. 
The SKBs are allocated anyway in the current driver so bottom line you trade off
some memory (the page_pool buffers) + a memcpy per packet and skip the dma
map/unmap which is the bottleneck in your hardware. 
I think it's fine


Powered by blists - more mailing lists