From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/2SxLvBeXoUEQhCBSSALmYkpZVwncUW9DNcWFc/8y/E=; b=qVhbo45OOASBnh9JJtrR+WCLXXRnoTUNXEZvUUS11L3wu9ywH8hEgWjhKo++OvlZVG 6LV2rM+HXPF1JYrzRqbkeLnD+dHZViLsHEBQOLn2IFYtUCYZQoeSs/IWgdcpfYEk7l+J yb0IDq9OS/GT81QS2nOpP+Gf94Dr1wxOf0ukomE2nhxYT8L0r2Xd5ZVNCWzgYKYX7exM OA2fBR9swm+Ugz16rWaNSKvUPk0VevY3a0Nu0Srvg7jCJRoE4zESNix80Jdz+s6puOMS to2Z+lYDuODzdLeJowOtHvQPgfnVSX7BStPv7S6JrNyZIC7pwGM5tk6MGEWFiDbSE3Vp c2og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/2SxLvBeXoUEQhCBSSALmYkpZVwncUW9DNcWFc/8y/E=; b=jufRj4eGHjzq6F/J//FNxcU2drz3kWciwJ7Ch5FpDYkp2uPja6PLjYrFeUI7kXpqYL 6Qt+j8+LBMamAxw4qMzUfcRoMljeUBSnSjAjiFxuH6M1bK/6O2eLkGE2Uz9OxdMTxaeh hrmiDtRy6orVXua2Fadtg4iKzlAQkMzHfkJIxHxIozVV/iEFYyqWQW3s0cxqIMLalNeL bAXdHoD4G0/xYz9vTJJcORsKlRHvSRmhmIloAhvGWP/eArkFio7SEBy/O84iVeCZRjpc eh+Af1VWSAZL7ARXnq212oP3+/uP61fzSFynoiwBvNey5B2/IzBrkYmv8oUPS48A2phr 2Krg== X-Gm-Message-State: AJcUukdSWAHeH2x1338B8KEAqryhipNqSgLL8YroQw+8fiQBEsc3np/8 k3KhDkymJjc+mrW399P03A0= X-Google-Smtp-Source: ALg8bN5zgIYKgDq5dNVLtAjAQ7R5375nJB9n5E8hmLMSRLBVoVX2aR4ei34WmQzgLFgQ0UriKSpUoA== X-Received: by 2002:a17:906:33db:: with SMTP id w27mr6864349eja.108.1548450918325; Fri, 25 Jan 2019 13:15:18 -0800 (PST) Received: from ?IPv6:2a02:120b:c3ce:5a20:78ce:526:cd04:6e80? ([2a02:120b:c3ce:5a20:78ce:526:cd04:6e80]) by smtp.gmail.com with ESMTPSA id e7-v6sm6700217ejt.23.2019.01.25.13.15.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Jan 2019 13:15:16 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Andriy Berestovskyy X-Mailer: iPhone Mail (16C101) In-Reply-To: Date: Fri, 25 Jan 2019 22:15:14 +0100 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 Content-Transfer-Encoding: quoted-printable 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> To: Ferruh Yigit Subject: Re: [dpdk-dev] [PATCH v3] ether: use a default for max Rx frame size in configure() 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, 25 Jan 2019 21:15:19 -0000 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.