From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ferruh Yigit Subject: Re: [PATCH v3 03/10] net/enic: heed the requested max Rx packet size Date: Wed, 14 Mar 2018 00:56:24 +0000 Message-ID: References: <20180306014634.28398-2-johndale@cisco.com> <20180308024702.25974-1-johndale@cisco.com> <20180308024702.25974-4-johndale@cisco.com> <2601191342CEEE43887BDE71AB97725890F22461@irsmsx105.ger.corp.intel.com> <20180310003743.GA18664@HYONKIM-FTCPE.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: "Ananyev, Konstantin" , John Daley , "dev@dpdk.org" , Wenzhuo Lu To: Hyong Youb Kim Return-path: Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 6F18C6D45 for ; Wed, 14 Mar 2018 01:56:29 +0100 (CET) In-Reply-To: <20180310003743.GA18664@HYONKIM-FTCPE.cisco.com> Content-Language: en-US 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 3/10/2018 12:37 AM, Hyong Youb Kim wrote: > On Fri, Mar 09, 2018 at 03:57:46PM +0000, Ferruh Yigit wrote: >> On 3/9/2018 3:51 PM, Ananyev, Konstantin wrote: > [...] >>>> 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 >>> >>> I think there are quite a lot apps these days that might rely on setting MTU via >>> rxmode.max_rx_pkt_len. >>> I think we need to support them till we (ever) deprecate rxmode.max_rx_pkt_len. >> >> Right. I was trying to save effort in case something changes related >> max_rx_pkt_len, but since it is not clear yet, will continue with this patch. >> >>> Konstantin >>> > > testpmd has a command to change max_rx_pkt_len, a few DTS test cases > rely on this feature to see if packets of certain sizes get dropped, > and so on. We worked on this patch to support these cases. > > I prefer using only MTU, to follow the convention of most (all?) > OSes. Though, this feature (max_rx_pkt_len) seems to come straight > from an Intel 82599 feature. In its datasheet, see "8.2.3.22.13 Max > Frame Size -- MAXFRS". Like to understand use cases for that, if > anyone can share. ixgbe driver updates MAXFRS register in ixgbe_dev_mtu_set(), so mtu seems can replace max_rx_pkt_len. MAXFRS is for rx only, from datasheet description of it: "This value has no effect on transmit frames; it is the responsibility of software to limit the size of transmit frames" This may be the reason a new variable has been created for rx_frames, to differentiate it from mtu. Not sure if max rx and tx size can be different values for ixgbe. > > -Hyong >