From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id BE9A45F54 for ; Fri, 9 Mar 2018 16:03:45 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2018 07:03:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,446,1515484800"; d="scan'208";a="181335218" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.62]) ([10.237.221.62]) by orsmga004.jf.intel.com with ESMTP; 09 Mar 2018 07:03:43 -0800 To: John Daley Cc: dev@dpdk.org, Hyong Youb Kim References: <20180306014634.28398-2-johndale@cisco.com> <20180308024702.25974-1-johndale@cisco.com> <20180308024702.25974-4-johndale@cisco.com> From: Ferruh Yigit Message-ID: Date: Fri, 9 Mar 2018 15:03:42 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180308024702.25974-4-johndale@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v3 03/10] net/enic: heed the requested max Rx packet size 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: , X-List-Received-Date: Fri, 09 Mar 2018 15:03:46 -0000 On 3/8/2018 2:46 AM, John Daley wrote: > From: Hyong Youb Kim > > Currently, enic completely ignores the requested max Rx packet size > (rxmode.max_rx_pkt_len). The desired behavior is that the NIC hardware > drops packets larger than the requested size, even though they are > still smaller than MTU. Your description looks reasonable but is there reason of two levels of limits, max_rx_pkt_len and MTU, why not just use MTU. There is already a mail thread to clarify max_rx_pkt_len [1]. Is this work based on an application that uses max_rx_pkt_len and to make PMD compatible with that application? If so we can continue with patch, but if the patch is to implement DPDK properly I suggest postponing this until max_rx_pkt_len clarified. [1] https://dpdk.org/ml/archives/dev/2018-March/092178.html > > Cisco VIC does not have such a feature. But, we can accomplish a > similar (not same) effect by reducing the size of posted receive > buffers. Packets larger than the posted size get truncated, and the > receive handler drops them. This is also how the kernel enic driver > enforces the Rx side MTU. > > This workaround works only when scatter mode is *not* used. When > scatter is used, there is currently no way to support > rxmode.max_rx_pkt_len, as the NIC always receives packets up to MTU. > > For posterity, add a copious amount of comments regarding the > hardware's drop/receive behavior with respect to max/current MTU. > > Signed-off-by: Hyong Youb Kim > Reviewed-by: John Daley <...>