From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6A678A034C; Mon, 8 Aug 2022 16:41:23 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 13FB64067B; Mon, 8 Aug 2022 16:41:23 +0200 (CEST) Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) by mails.dpdk.org (Postfix) with ESMTP id F308F4014F for ; Mon, 8 Aug 2022 16:41:21 +0200 (CEST) Received: by mail-pj1-f50.google.com with SMTP id p14-20020a17090a74ce00b001f4d04492faso9264478pjl.4 for ; Mon, 08 Aug 2022 07:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=hIgCrxP+4fw0j/vyExwY6EXFrk3j/sIp6Y0Y7WjwU3w=; b=X0kbcT0Na61eppzxmP7NQyZHMCkjKYoUe+m7mEcKQ4PT7JA79sBrtizHwEVBAC4dZo gmiiM9zSyGF/WQd12AR3aeEhztEov6O7w1yaF+rhSYzh54hyJAq2qDgq0ASOCVBnMaKQ Kutk7ZUCmPiRVEyYpcJA8j4FDe4gNGT6TN9Ob1rvM5Rl4v+o0kOquhFhGoE5JvzW1Laz NVNvqX2xeORF/4bEuvmwPYuPPzuIO7utH1qsdCBDKwCUP8h+IsR62hd34tFu+BJ2aTcN /vOGU/0oae/20ougbmVW/cB7YBc1s2YzHjf1aui1MtUNbNNxHXA0aGp+R+Q2jgPpAa6n tYTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=hIgCrxP+4fw0j/vyExwY6EXFrk3j/sIp6Y0Y7WjwU3w=; b=15aZweX++nhhD3bh6ue+6olLgNu1GfEqeupO0QH0/NL9zqcIZRiIRlPnML98lzr6ha ynyHxqFCkrW2bqs1VpRbpb83zJS0R/mUtEdbkJzSVpMS4V11SsNTnLNl57BtX2RWUHb3 hqCyFrb4TI8qUOjkG9rC8bRsZ2q0aQo+wkheF0Es2rpYL3Ncng2hoEoTiT0orbC2UPes lgCahUhXJscbQmZYauzvFfbyCjVlE+rY87OBZ4L28eDtCZQEPPZq0u/aeHqjH6OAg7eY 0AgGc8xXVlw7wx3vxV3jwwWlP5ZhdQwZhw5UGL6oOnYbyTedOo8IBnusRlAn8d73ird2 26/w== X-Gm-Message-State: ACgBeo3y3bsFAZN7LZJQFT6Oebl0Yd53mUigXLQysB0tPkHUnq88LaOv ZXojWLumLz4n05rdIPrldxBQNinehGtQPQ== X-Google-Smtp-Source: AA6agR5RtXVXV41Zo8L6p3EadjNu+N1fFJutJ04TkfKTcXScMehDJkBQS2wkAEdoZ9Oy42YSmR6cuw== X-Received: by 2002:a17:902:d546:b0:16e:c70c:fdf5 with SMTP id z6-20020a170902d54600b0016ec70cfdf5mr19308987plf.100.1659969680889; Mon, 08 Aug 2022 07:41:20 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id d138-20020a621d90000000b0052d82ce65a9sm8957983pfd.143.2022.08.08.07.41.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Aug 2022 07:41:20 -0700 (PDT) Date: Mon, 8 Aug 2022 07:41:19 -0700 From: Stephen Hemminger To: Francesco Mancino Cc: dev@dpdk.org Subject: Re: [PATCH] net/tap: Allow jumbo frames Message-ID: <20220808074119.120c63c1@hermes.local> In-Reply-To: <315474c3-7004-2114-9e24-8344da7aca9e@tutus.se> References: <315474c3-7004-2114-9e24-8344da7aca9e@tutus.se> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Mon, 8 Aug 2022 11:31:16 +0200 Francesco Mancino wrote: > eth_dev_validate_mtu, introduced in 990912e676e, validates configured > MTU plus overhead against max_rx_pktlen. > Since TAP is a virtual device, it should support as big MTU as possible. > --- > =C2=A0drivers/net/tap/rte_eth_tap.c | 2 +- > =C2=A01 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c > index 9e1032fe72..54ca4ca5e9 100644 > --- a/drivers/net/tap/rte_eth_tap.c > +++ b/drivers/net/tap/rte_eth_tap.c > @@ -1066,7 +1066,7 @@ tap_dev_info(struct rte_eth_dev *dev, struct=20 > rte_eth_dev_info *dev_info) >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dev_info->if_index =3D intern= als->if_index; > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dev_info->max_mac_addrs =3D 1; > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dev_info->max_rx_pktlen =3D (uint32= _t)RTE_ETHER_MAX_VLAN_FRAME_LEN; > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dev_info->max_rx_pktlen =3D (uint32= _t)RTE_ETHER_MAX_JUMBO_FRAME_LEN; > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dev_info->max_rx_queues =3D R= TE_PMD_TAP_MAX_QUEUES; > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dev_info->max_tx_queues =3D R= TE_PMD_TAP_MAX_QUEUES; > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dev_info->min_rx_bufsize =3D = 0; > -- > 2.34.1 >=20 >=20 OK but cast is not needed. It wasn't needed before and not needed now. By not having the cast the code has better chance of catching any issues if sizes mismatch.