From mboxrd@z Thu Jan 1 00:00:00 1970 From: Toshiaki Makita Subject: Re: [PATCH RFC 4/9] veth: Use NAPI for XDP Date: Wed, 2 May 2018 12:37:48 +0900 Message-ID: <55d391d1-da32-5748-ddda-272fb3e2c105@gmail.com> References: <20180424143923.26519-1-toshiaki.makita1@gmail.com> <20180424143923.26519-5-toshiaki.makita1@gmail.com> <20180501095008.207c354f@brouer.com> <79ff8b87-2ee2-ce60-36f3-6f3f79cb3272@lab.ntt.co.jp> <20180501104306.33c65bd8@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Toshiaki Makita , netdev@vger.kernel.org To: Jesper Dangaard Brouer Return-path: Received: from mail-pf0-f194.google.com ([209.85.192.194]:37734 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750823AbeEBDhw (ORCPT ); Tue, 1 May 2018 23:37:52 -0400 Received: by mail-pf0-f194.google.com with SMTP id e9so6591416pfi.4 for ; Tue, 01 May 2018 20:37:52 -0700 (PDT) In-Reply-To: <20180501104306.33c65bd8@redhat.com> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 18/05/01 (火) 17:43, Jesper Dangaard Brouer wrote: > On Tue, 1 May 2018 17:02:34 +0900 > Toshiaki Makita wrote: > >> On 2018/05/01 16:50, Jesper Dangaard Brouer wrote: >>> On Tue, 24 Apr 2018 23:39:18 +0900 >>> Toshiaki Makita wrote: >>> >>>> +static int veth_xdp_enqueue(struct veth_priv *priv, void *ptr) >>>> +{ >>>> + if (unlikely(ptr_ring_produce(&priv->xdp_ring, ptr))) >>>> + return -ENOSPC; >>>> + >>>> + return 0; >>>> +} >>> >>> Here we have a lock per (enqueued) packet. I'm working on changing the >>> ndo_xdp_xmit API to allow bulking. And the tun driver have exact same >>> issue/need. >> >> Probably I should have noted in commitlog, but this per-packet lock is >> removed in patch 9. >> I'm curious about if any change is needed by your new API. > > Again, I'm just moving this into the generic code, to avoid having to > implement this for every driver. > > Plus, with CONFIG_RETPOLINE we have the advantage of only calling > ndo_xdp_xmit once (indirect function pointer call). Nice. Once it becomes available I'll use it instead. Toshiaki Makita