From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zoltan Kiss Subject: ixgbe vPMD RX functions and buffer number minimum requirement Date: Fri, 24 Jul 2015 15:59:58 +0100 Message-ID: <55B252EE.9060306@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit To: "Richardson, Bruce" , "dev@dpdk.org" Return-path: Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by dpdk.org (Postfix) with ESMTP id CEE83C442 for ; Fri, 24 Jul 2015 16:59:58 +0200 (CEST) Received: by wibxm9 with SMTP id xm9so32768568wib.0 for ; Fri, 24 Jul 2015 07:59:58 -0700 (PDT) List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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. Regards, Zoltan