From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7FDD6A04B1; Fri, 28 Aug 2020 22:31:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2EBEA2B9E; Fri, 28 Aug 2020 22:31:01 +0200 (CEST) Received: from mail-pg1-f196.google.com (mail-pg1-f196.google.com [209.85.215.196]) by dpdk.org (Postfix) with ESMTP id 696401F1C for ; Fri, 28 Aug 2020 22:31:00 +0200 (CEST) Received: by mail-pg1-f196.google.com with SMTP id p37so981355pgl.3 for ; Fri, 28 Aug 2020 13:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=lWja8eTYXvki97o4fVNSmKMtOrfkNic0NW+6Kcy6Gpc=; b=LA1SVwIEaoJ8OpvNeZJUZqAdF3a0m4aO7A6xblBahSN9/Q/4IdZK+au1+0yCWdy8vR WQ2cLGYgh1nQFL4JRTwYCy9gAdRzmTI2X3v8K4R/C0mxf+mdoyVAQhP3MZIT2QrdSaMc jJ/MGgFIWOopkYaB5j6SSghXA+GqlKRJh1ZYKejnogQV+8x60nAna4ak+Gr0uk4VNCJD FRwZFKRXpE4IFeHAJfxGc2Hku3Dj1mjWgzQ8NhHc6YKltG9iqIJfium7XuuYJlWii5jP /BZq3c7o0229D7av4hjANN0XcROSj83yxqlMKjmSKJCWIEha23PojhDtmTb3YAVVyq9D yvzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=lWja8eTYXvki97o4fVNSmKMtOrfkNic0NW+6Kcy6Gpc=; b=O0+sRahPL4Xg+ni9A/s/vbO1/fOPNhAaHS+6WMTFV1ccAYAQo0u39NKjZpZvlxRHOf R43nyqhJrsA5Lqxj27mWRKThTRQ0rgguGnGUo91NeZDrlihuGP/ysKvE5p9m9uA0QwFA /IMmpAxxMZDmZb4T6BUepk1pxIm0w9VnrxEAFqPtalkoVxsFI6ojp+mYzIIC/rv8v3XM SwQPzuVDj4DPykcwLYIkqMsKlLXfgTRG4xNLVXjOiTjIo/oT4h6W8A39R/JosoWZ20Z6 nuXNq7JofzOc3W5S6yGaMaqI4rmn2wqZf94UBhoa3vKxOlFKjII1O/ZgarLaXaqkvgAs Mciw== X-Gm-Message-State: AOAM531BScFDKXRqr0W41NilOAOBWe9RzNiV7h2ELcrdB4bx2wGzobAc JRLf9LyYQloOPH4Lv8yR4ZmljQ== X-Google-Smtp-Source: ABdhPJzxKNhYgJYa5BTRSUP7I+2Isgad3JmurcREjKfGtDXaYPetwNpGsQ5eH23JMNFM9Q6kph0hOw== X-Received: by 2002:a62:6451:: with SMTP id y78mr621727pfb.2.1598646659378; Fri, 28 Aug 2020 13:30:59 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id w5sm333920pgk.20.2020.08.28.13.30.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Aug 2020 13:30:58 -0700 (PDT) Date: Fri, 28 Aug 2020 13:30:50 -0700 From: Stephen Hemminger To: Jeff Guo Cc: "Wang, Haiyue" , Morten =?UTF-8?B?QnLDuHJ1cA==?= , "Yang, Qiming" , "Xing, Beilei" , "Zhao1, Wei" , "Zhang, Qi Z" , "Wu, Jingjing" , "Richardson, Bruce" , "dev@dpdk.org" , "Zhang, Helin" , "Yigit, Ferruh" , "barbette@kth.se" Message-ID: <20200828133050.74e38bf3@hermes.lan> In-Reply-To: <77c760bb-7034-72b6-d4ba-c970764b7f3d@intel.com> References: <20200827101008.76906-1-jia.guo@intel.com> <98CBD80474FA8B44BF855DF32C47DC35C6125C@smartserver.smartshare.dk> <77c760bb-7034-72b6-d4ba-c970764b7f3d@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2 0/5] maximize vector rx burst for PMDs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, 28 Aug 2020 14:39:33 +0800 Jeff Guo wrote: > >> I am not sure about this, but if I read it correctly, calling rte_eth_rx_burst() with nb_pkts = 33 > >> (not 32) would only return 32 packets, even if more packets are available. (I assume that > >> RTE_I40E_DESCS_PER_LOOP is 32.) In this case, I guess that you need to read the remaining of the > >> requested packets using the non-vector function in order to support any nb_pkts value. > >> > > This is vector instruction handling design requirement, like for avx2: #define ICE_DESCS_PER_LOOP_AVX 8, > > if deep into the real loop handling, you will get the point why doing RTE_ALIGN_FLOOR. ;-) > > > > _ice_recv_raw_pkts_vec_avx2: > > for (i = 0, received = 0; i < nb_pkts; i += ICE_DESCS_PER_LOOP_AVX, rxdp += ICE_DESCS_PER_LOOP_AVX) > > > > Maybe it is worth to tell PMD to stop using vector by calling rte_eth_rx_queue_setup with the application > > burst size it wants. There is no need for yet another nerd knob in DPDK. The driver must accept any burst size > 0. If it wants to optimize for certain multiples, then it can do so in its burst handler. Like any optimized checksum calculator does. Let the CPU branch predictor do its job and find the best path through the driver code. Something like: uint16_t my_driver_recv_burst((void *prxq, struct rte_mbuf **rx_pkts, uint16_t nb_pkts) { if (nb_pkts == 32) return my_driver_recv_burst32(prxq, rx_pkts, nb_pkts); ... else return my_driver_recv_burstN(prxq, rx_pkts, nb_pkts); ... } You could repeatedly call the burst32 if passed large nb_pkts.