netdev - Re: [PATCH net] net/mlx5e: Do not recycle pages from emergency reserve

lists.openwall.net		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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CALzJLG-K0eDRzr_QcXxYth-hrnSKRtT96-7j=RUC703Gg2hqUw@mail.gmail.com>
Date:   Tue, 24 Jan 2017 11:21:18 +0200
From:   Saeed Mahameed <saeedm@....mellanox.co.il>
To:     Jesper Dangaard Brouer <brouer@...hat.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        Tom Herbert <tom@...bertland.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        netdev <netdev@...r.kernel.org>,
        Tariq Toukan <tariqt@...lanox.com>, Davem <davem@...emloft.net>
Subject: Re: [PATCH net] net/mlx5e: Do not recycle pages from emergency reserve

On Mon, Jan 23, 2017 at 11:14 AM, Jesper Dangaard Brouer
<brouer@...hat.com> wrote:
> On Sat, 21 Jan 2017 11:26:49 -0800
> Eric Dumazet <eric.dumazet@...il.com> wrote:
>
>> > My previous measurements show approx 20℅ speedup on a UDP test with
>> > delivery to remote CPU.
>> >
>> I find this a bit strange. When you have time (ie not while driving your
>> car or during week end) please give more details, for example on message
>> size.
>
> I tested this with both 64 bytes and 1500 bytes.  After I moved to 50G
> and 100G testing then I don't need to use 64 bytes packets to provoke
> the bottlenecks in the stack ;-)
>

Exactly! for XDP like uses cases, page cache maybe a non required optimization.
but when you start testing a typical TCP use cases over 50/100G link
you will need
more buffers (pages) to host the traffic for longer periods, you will
hit that bottleneck.

>> Was it before skb_condense() was added ?
>
> It tested this just before skb_condense() was added.  BUT
> skb_condense() does not get activated when using mlx5, because uses
> build_skb() ie. not using frags.
>

Well, we can always replace build_skb with alloc_skb +
memcpy(skb->data, headlen) + add_skb_frag(payload)
does it it worth it ? and is it healthy that both skb->data and
skb_shinfo(skb)->frags[i] point to the same page ?

> For people that don't realize this:
>  Eric's optimization in skb_condense() is about trading remote CPU
>  atomic refcnt (put_page) for copy + local CPU refcnt dec.
>
> My measurements show cycles cost local=31 vs. remote=208, thus a
> estimated saving around 177 cycles.  Which is spend on calling a fairly
> complex function __pskb_pull_tail(), and only works for more complex
> SKBs with frags.
>
> --
> Best regards,
>   Jesper Dangaard Brouer
>   MSc.CS, Principal Kernel Engineer at Red Hat
>   LinkedIn: http://www.linkedin.com/in/brouer