From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by dpdk.org (Postfix) with ESMTP id 8778DC53C for ; Mon, 27 Jul 2015 13:38:31 +0200 (CEST) Received: by wibud3 with SMTP id ud3so111577387wib.0 for ; Mon, 27 Jul 2015 04:38:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ByY+YiKucskhwtrxH5M3gmtOluX0kSjDZJiF2ZHcStQ=; b=f0CgMxIV6L2Unmxe/2aCH2A5zqAGP7gUL7eNYTaIDXXLs4GSBeOC3pAd0oNw+ikLzU rHHnOk+MlWnC+pCpocWk63b4k45qYLg2CskulOHGBNNZmIysybtLYCXIbaxRrE7rZrfw QlXivCYJRBbKYaVskrTOoyym1MRzmem7eE+dzAj3bjpA1CCoNtOMGKAAsaQQqV6kkaYa d1FEwtV9emh9nkx1sRdH2zw1jdJ5wl61sYvUNpoa0AJKIuGfOhBrLhwZpdJd9RB1bPFP LduJkAmrXm4pxeumCc7IBLbtbC1DcyeyYtaVMOCgHTSFRAEaRpb12vFPoPOV4Kt51npl aLaQ== X-Gm-Message-State: ALoCoQm4w3+mdf7YTBuHf2m158JV1rNJb+C8aqVDbGq4QvwOaHllgzNplhWtlrmFpeLTd085I+sJ X-Received: by 10.194.238.168 with SMTP id vl8mr55621749wjc.128.1437997111351; Mon, 27 Jul 2015 04:38:31 -0700 (PDT) Received: from [192.168.0.101] ([90.152.119.35]) by smtp.googlemail.com with ESMTPSA id l14sm2077236wjq.21.2015.07.27.04.38.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jul 2015 04:38:30 -0700 (PDT) Message-ID: <55B61835.9010908@linaro.org> Date: Mon, 27 Jul 2015 12:38:29 +0100 From: Zoltan Kiss User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "Ananyev, Konstantin" , "Richardson, Bruce" , "dev@dpdk.org" References: <55B252EE.9060306@linaro.org> <2601191342CEEE43887BDE71AB97725836A68558@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB97725836A68558@irsmsx105.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] ixgbe vPMD RX functions and buffer number minimum requirement X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 11:38:31 -0000 Hi Konstantin, Thanks! Another question I would have: why does _recv_raw_pkts_vec() insist on (nb_pkts > RTE_IXGBE_VPMD_RX_BURST)? Looking at the code it should be able to return packets when nb_pkts >= RTE_IXGBE_DESCS_PER_LOOP. The split_flags check in ixgbe_recv_scattered_pkts_vec() would be a bit more complicated, and therefore maybe would have a tiny performance overhead as well, but I don't it would be anything serious. Regards, Zoltan On 24/07/15 17:43, Ananyev, Konstantin wrote: > Hi Zoltan, > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Zoltan Kiss >> Sent: Friday, July 24, 2015 4:00 PM >> To: Richardson, Bruce; dev@dpdk.org >> Subject: [dpdk-dev] ixgbe vPMD RX functions and buffer number minimum requirement >> >> Hi, >> >> I was thinking how to handle the situation when you call >> rte_eth_rx_burst with less than RTE_IXGBE_VPMD_RX_BURST buffers. In >> ODP-DPDK unfortunately we can't force this requirement onto the calling >> application. >> One idea I had to check in ixgbe_recv_pkts_vec() if nb_pkts < >> RTE_IXGBE_VPMD_RX_BURST, and call ixgbe_recv_pkts_bulk_alloc in that >> case. Accordingly, in ixgbe_recv_scattered_pkts_vec() we could call >> ixgbe_recv_scattered_pkts() in this case. A branch predictor can easily >> eliminate the performance penalty of this, and applications can use >> whatever burst size feasible for them. >> The obvious problem could be whether you can mix the receive functions >> this way. I have a feeling it wouldn't fly, but I wanted to ask first >> before spending time investigate this option further. > > No, it is not possible to mix different RX functions, they setup/use ixgbe_rx_queue > fields in a different manner. > Konstantin > >> >> Regards, >> >> Zoltan