netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Dumazet <edumazet@google.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: "David S . Miller" <davem@davemloft.net>,
	netdev <netdev@vger.kernel.org>,
	Tariq Toukan <tariqt@mellanox.com>,
	Saeed Mahameed <saeedm@mellanox.com>,
	Willem de Bruijn <willemb@google.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Alexander Duyck <alexander.duyck@gmail.com>
Subject: Re: [PATCH net-next] mlx4: Better use of order-0 pages in RX path
Date: Mon, 13 Mar 2017 10:50:28 -0700	[thread overview]
Message-ID: <CANn89iL_C8CMaxmkSvFxBMCjHx49JkEaKGoUPWMRYucrx09LnA@mail.gmail.com> (raw)
In-Reply-To: <20170313173432.GA31333@ast-mbp.thefacebook.com>

On Mon, Mar 13, 2017 at 10:34 AM, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Sun, Mar 12, 2017 at 05:58:47PM -0700, Eric Dumazet wrote:
>> @@ -767,10 +814,30 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
>>                       case XDP_PASS:
>>                               break;
>>                       case XDP_TX:
>> +                             /* Make sure we have one page ready to replace this one */
>> +                             npage = NULL;
>> +                             if (!ring->page_cache.index) {
>> +                                     npage = mlx4_alloc_page(priv, ring,
>> +                                                             &ndma, numa_mem_id(),
>> +                                                             GFP_ATOMIC | __GFP_MEMALLOC);
>
> did you test this with xdp2 test ?
> under what conditions it allocates ?
> It looks dangerous from security point of view to do allocations here.
> Can it be exploited by an attacker?
> we use xdp for ddos and lb and this is fast path.
> If 1 out of 100s XDP_TX packets hit this allocation we will have serious
> perf regression.
> In general I dont think it's a good idea to penalize x86 in favor of powerpc.
> Can you #ifdef this new code somehow? so we won't have these concerns on x86?

Normal paths would never hit this point really. I wanted to be extra
safe, because who knows, some guys could be tempted to set
ethtool -G ethX  rx 512 tx 8192

Before this patch, if you were able to push enough frames in TX ring,
you would also eventually be forced to allocate memory, or drop frames...

This patch does not penalize x86, quite the contrary.
It brings a (small) improvement on x86, and a huge improvement on powerpc.

Thanks.

  reply	other threads:[~2017-03-13 17:50 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-13  0:58 [PATCH net-next] mlx4: Better use of order-0 pages in RX path Eric Dumazet
2017-03-13 12:01 ` Tariq Toukan
2017-03-13 12:54   ` Eric Dumazet
2017-03-13 12:15 ` kbuild test robot
2017-03-13 12:50 ` kbuild test robot
2017-03-13 13:07   ` Eric Dumazet
2017-03-13 13:16     ` Eric Dumazet
2017-03-13 17:34 ` Alexei Starovoitov
2017-03-13 17:50   ` Eric Dumazet [this message]
2017-03-13 18:31     ` Alexei Starovoitov
2017-03-13 18:58       ` Eric Dumazet
2017-03-13 20:23         ` Alexei Starovoitov
2017-03-13 21:09           ` Eric Dumazet
2017-03-13 23:21             ` Alexei Starovoitov
2017-03-13 23:28               ` Eric Dumazet
2017-03-13 23:40                 ` Alexei Starovoitov
2017-03-13 23:44                   ` Eric Dumazet
2017-03-13 23:51                     ` Alexei Starovoitov
2017-03-14  1:02                   ` Eric Dumazet
2017-03-14  4:57                     ` Alexei Starovoitov
2017-03-14 13:34                       ` Eric Dumazet
2017-03-14 14:21                         ` Eric Dumazet
2017-03-15 15:33                           ` Tariq Toukan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANn89iL_C8CMaxmkSvFxBMCjHx49JkEaKGoUPWMRYucrx09LnA@mail.gmail.com \
    --to=edumazet@google.com \
    --cc=alexander.duyck@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=saeedm@mellanox.com \
    --cc=tariqt@mellanox.com \
    --cc=willemb@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).