From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andriy Berestovskyy Subject: Re: [PATCH v3] ether: use a default for max Rx frame size in configure() Date: Fri, 25 Jan 2019 22:15:14 +0100 Message-ID: <4AE0F12B-B6FA-4868-A260-69F3C13EE37F@gmail.com> References: <1490288768-8114-1-git-send-email-Andriy.Berestovskyy@cavium.com> <1719643.qo6JmGv4pL@xps> <7564896.sbN2ypR4X7@xps> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Shahaf Shuler , Thomas Monjalon , "dev@dpdk.org" , Bruce Richardson , "arybchenko@solarflare.com" , "hemant.agrawal@nxp.com" , "jerin.jacob@cavium.com" , Olivier MATZ , Stephen Hemminger To: Ferruh Yigit Return-path: Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) by dpdk.org (Postfix) with ESMTP id D7B5C91 for ; Fri, 25 Jan 2019 22:15:18 +0100 (CET) Received: by mail-ed1-f67.google.com with SMTP id o10so8393468edt.13 for ; Fri, 25 Jan 2019 13:15:18 -0800 (PST) In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Sure, Ferruh. Just let me know how can I help you. Andriy > On 23 Jan 2019, at 19:36, Ferruh Yigit wrote: >=20 >> On 5/24/2018 10:20 AM, Andriy Berestovskyy wrote: >> Hi Shahaf, >>=20 >>> On 23 May 2018, at 07:21, Shahaf Shuler wrote: >>> I think this patch addressing just small issue in a bigger problem. >>> The way I see it all application needs to specify is the max packet size= it expects to receive, nothing else(!).=20 >>=20 >> [...] >>=20 >>> IMO The "jumbo_frame" bit can be set by the underlying PMD directly to t= he device registers given the max_rx_pkt_len configuration.=20 >>=20 >> Sure, it can be deducted in PMD if max_rx_pkt_len is greater than the nor= mal frame size. >>=20 >> The background behind this patch was to fix some examples on some platfor= ms by allowing them to just set the jumbo bit in config and let the DPDK to d= educt the optimal jumbo max_rx_pkt_len. >>=20 >> There was also another patch which fixed those examples, so they first qu= ery the max_rx_pkt_len and then pass it with the config: >> http://dpdk.org/commit/5e470a6654 >>=20 >> That patch has been merged, so now we can fix/change the API in any way w= e decide, there is no urgency anymore. >>=20 >> Looks like the jumbo bit in config is redundant, but there might be other= opinions. >=20 > Back to this old issue, the mentioned inconsistency is still exist in the > current code, and this or relevant ones mentioned a few times already. >=20 > What would you think about developing an unit test on 19.05 to test these o= n > ethdev, and ask vendors to run it and fix failures in next releases? > A more TDD approach, first right the test that fails, later fix it. > If there is a support I can start writing it but will require support. >=20 >=20 > And related issues: > max_rx_pkt_len > DEV_RX_OFFLOAD_JUMBO_FRAME > DEV_TX_OFFLOAD_MULTI_SEGS > scattered_rx > mtu >=20 >=20 > These are provided by user as config option, but some drivers updates some= of > them, initial question is, are they input only or can be modified by drive= rs. >=20 > Like if user not requested JUMBO_FRAME but provided a large max_rx_pkt_len= , > should user get an error or should PMD enable jumbo frame itself? >=20 >=20 > And another question around 'max_rx_pkt_len' / 'mtu', both are related and= > close. 'max_rx_pkt_len' is frame size as far as I can understand, and sinc= e we > have capability to set 'mtu', this looks duplicate. > And I assume users are mostly will be interested in 'mtu', for given 'mtu'= > driver can calculate 'max_rx_pkt_len' taking other config options into acc= ount > affecting frame size.