From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0061.outbound.protection.outlook.com [104.47.0.61]) by dpdk.org (Postfix) with ESMTP id 30C8316E for ; Wed, 23 May 2018 07:21:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rd1YwocHTGtKSiiuY8XIzchXWnHkeU3nISNu3jy9xhA=; b=qhLNxns7XfIIrDSlQMoGdHFUFothknZ06W7KWDMObN3vBqGTXj/GA8pvgmhh1s9nid68ZXgqMPj+5ZrLC8WyZJKCU7zVGeMfyntyfGAZln1RKozPGNTXOEqNt+w9ri3S4W2F6l4S6A1R2NbDjdqxfYN55jBYD7jIgIOuxWF81vQ= Received: from DB7PR05MB4426.eurprd05.prod.outlook.com (52.134.109.15) by DB7PR05MB4380.eurprd05.prod.outlook.com (52.134.108.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.776.11; Wed, 23 May 2018 05:21:43 +0000 Received: from DB7PR05MB4426.eurprd05.prod.outlook.com ([fe80::e57e:5e77:595f:d4f7]) by DB7PR05MB4426.eurprd05.prod.outlook.com ([fe80::e57e:5e77:595f:d4f7%13]) with mapi id 15.20.0776.015; Wed, 23 May 2018 05:21:43 +0000 From: Shahaf Shuler To: Thomas Monjalon , Andriy Berestovskyy CC: "dev@dpdk.org" , Bruce Richardson , "ferruh.yigit@intel.com" , "arybchenko@solarflare.com" , "hemant.agrawal@nxp.com" , "jerin.jacob@cavium.com" Thread-Topic: [dpdk-dev] [PATCH v3] ether: use a default for max Rx frame size in configure() Thread-Index: AQHSvQouUaqBPrnnUU2kzlgAF/F1fqQ+vwwSgABuqWA= Date: Wed, 23 May 2018 05:21:43 +0000 Message-ID: References: <1490288768-8114-1-git-send-email-Andriy.Berestovskyy@cavium.com> <1719643.qo6JmGv4pL@xps> <7564896.sbN2ypR4X7@xps> In-Reply-To: <7564896.sbN2ypR4X7@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=shahafs@mellanox.com; x-originating-ip: [31.154.10.105] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB7PR05MB4380; 7:0xIDjJmvLg9VgB6YvGEwADV9n9Llptyvkfex1+5+3bs6F/mXNmg9OUAcgmMGr9yvUTOilBNdJt8LE3b3dhlkGNWsaGgQFKjnlA2D8a9xyHWWG9t8MC1AevLM+bkVpEGJ62l4iU3A+YtsMpWCy3ywuCvl8PTZtZnZSiiS4SoRJsvIiGYjGzbd6lRdwCPBNq65XXTmLKj+gi+wiggSr7iGTKgs9IeaqaXz/vdFJCiF/YsK3NlgdXmJ5Vts2PbhuNYQ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB7PR05MB4380; x-ms-traffictypediagnostic: DB7PR05MB4380: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:DB7PR05MB4380; BCL:0; PCL:0; RULEID:; SRVR:DB7PR05MB4380; x-forefront-prvs: 06818431B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(346002)(39860400002)(376002)(39380400002)(189003)(199004)(102836004)(5660300001)(4326008)(26005)(68736007)(86362001)(486006)(5250100002)(476003)(76176011)(99286004)(8656006)(186003)(2900100001)(7736002)(305945005)(2906002)(3280700002)(97736004)(25786009)(3660700001)(478600001)(8936002)(81156014)(81166006)(74316002)(8676002)(6506007)(9686003)(105586002)(106356001)(93886005)(446003)(53936002)(66066001)(6436002)(229853002)(14454004)(316002)(6116002)(3846002)(11346002)(7696005)(33656002)(6246003)(55016002)(54906003)(59450400001)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR05MB4380; H:DB7PR05MB4426.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: HT4xlSzSEmvBONHLIRlI/cKEaPX1O15FuSuBZfSJKI/mZkb6UeL9xfuhQtUUkIqkCrB1X/h2VS42/qLkykYEFiVQe8ZBUkHEwpLaLzHwisyzwVhzrrzu0gYjXZ8usrunxtEgVx7JDoeD6hjjWLNVjCe1ybh2BIgNFwJwp9s3wn3ojXHqPfCXKhuehRtFNqW7 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 344db5be-2b8d-424b-683d-08d5c06d1247 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 344db5be-2b8d-424b-683d-08d5c06d1247 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2018 05:21:43.2024 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR05MB4380 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: Wed, 23 May 2018 05:21:45 -0000 Hi Andriy, 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 Currently we are forcing it to toggle multiple redundant fields.=20 Wednesday, May 23, 2018 1:31 AM, Thomas Monjalon: > Subject: Re: [dpdk-dev] [PATCH v3] ether: use a default for max Rx frame > > > > > > IMO the changes are transparent for the PMDs (please see below), but > > > it might affect some applications. Here is the change in API behaviou= r: > > > > > > Before the patch: > > > jumbo =3D=3D 0, max_rx_pkt_len =3D=3D 0, RESULT: max_rx_pkt_len =3D > > > ETHER_MAX_LEN jumbo =3D=3D 0, max_rx_pkt_len =3D=3D 10, RESULT: > > > max_rx_pkt_len =3D ETHER_MAX_LEN jumbo =3D=3D 0, max_rx_pkt_len =3D= =3D > 1200, > > > RESULT: max_rx_pkt_len =3D 1200 jumbo =3D=3D 0, max_rx_pkt_len =3D=3D= 9K, > > > RESULT: max_rx_pkt_len =3D ETHER_MAX_LEN > > > > > > jumbo =3D=3D 1, max_rx_pkt_len =3D=3D 0, RESULT: ERROR jumbo =3D=3D 1= , > > > max_rx_pkt_len =3D=3D 10, RESULT: ERROR jumbo =3D=3D 1, max_rx_pkt_le= n =3D=3D > > > 1200, RESULT: max_rx_pkt_len =3D 1200 jumbo =3D=3D 1, max_rx_pkt_len = =3D=3D > > > 9K, RESULT: ERROR or max_rx_pkt_len =3D 9K jumbo =3D=3D 1, max_rx_pkt= _len > > > =3D=3D 90K, RESULT: ERROR > > > > > > > > > After the patch: > > > jumbo =3D=3D 0, max_rx_pkt_len =3D=3D 0, RESULT: max_rx_pkt_len =3D > > > ETHER_MAX_LEN jumbo =3D=3D 0, max_rx_pkt_len =3D=3D 10, RESULT: ERROR > > > (changed) jumbo =3D=3D 0, max_rx_pkt_len =3D=3D 1200, RESULT: > max_rx_pkt_len > > > =3D 1200 jumbo =3D=3D 0, max_rx_pkt_len =3D=3D 9K, RESULT: ERROR (cha= nged) For example in the line above - the application wants to receive 9K frames.= Why it is an error? Why forcing the application to set another redundant b= it? IMO The "jumbo_frame" bit can be set by the underlying PMD directly to the = device registers given the max_rx_pkt_len configuration.=20 Same apply to DEV_RX_OFFLOAD_SCATTER flag. Application doesn't need to set = it. the PMD will choose the put multiple mbufs in Rx descriptor given the m= buf size and the max_rx_packet_len.=20 API should be informative enough for the application to expect multi-segmen= t packets on the receive.=20 Finally the MTU. It is correct it stands for "max transmit unit" but it is = threaded in the same way max_rx_pkt_len is (i.e. MTU sets the max packet le= n the port receives).=20 We need to either clarify it only address transmit or remove it completely = and maybe change max_rx_pkt_len name to mtu.=20 > > > > > > jumbo =3D=3D 1, max_rx_pkt_len =3D=3D 0, RESULT: max_rx_pkt_len =3D d= ev_info() > > > jumbo =3D=3D 1, max_rx_pkt_len =3D=3D 10, RESULT: ERROR jumbo =3D=3D = 1, > > > max_rx_pkt_len =3D=3D 1200, RESULT: max_rx_pkt_len =3D 1200 jumbo =3D= =3D 1, > > > max_rx_pkt_len =3D=3D 9K, RESULT: ERROR or max_rx_pkt_len =3D 9K jumb= o > =3D=3D > > > 1, max_rx_pkt_len =3D=3D 90K, RESULT: ERROR > > > > > > Only the apps which requested too small or too big normal frames > > > will be affected. In most cases it will be rather an error in the app= ... > > > > > > > > > Also I have looked through all the PMDs to confirm they are not > > > affected. Here is the summary: > > > > > > af_packet > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D ETH_FRAME_LEN (1514) > > > > > > ark > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D ETH_FRAME_LEN (16K - 128) > > > > > > avp > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D avp->max_rx_pkt_len > > > rx_queue_setup() uses max_rx_pkt_len for scattering > > > > > > bnx2x > > > configure() uses max_rx_pkt_len to set internal mtu > > > info() returns max_rx_pktlen =3D BNX2X_MAX_RX_PKT_LEN (15872) > > > > > > bnxt > > > configure() uses max_rx_pkt_len to set internal mtu > > > info() returns max_rx_pktlen =3D BNXT_MAX_MTU + ETHER_HDR_LEN + > > > ETHER_CRC_LEN + VLAN_TAG_SIZE (9000 + 14 + 4 + 4) > > > > > > bonding > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D internals->candidate_max_rx_pktlen o= r > > > ETHER_MAX_JUMBO_FRAME_LEN (0x3F00) > > > > > > cxgbe > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D CXGBE_MAX_RX_PKTLEN (9000 + 14 + 4) > > > rx_queue_setup() checks max_rx_pkt_len boundaries > > > > > > dpaa2 > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D DPAA2_MAX_RX_PKT_LEN (10240) > > > > > > e1000 (em) > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D em_get_max_pktlen() (0x2412, 0x1000, > > > 1518, 0x3f00, depends on model) > > > > > > e1000 (igb) > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D 0x3fff > > > start() writes max_rx_pkt_len to HW for jumbo frames only > > > start() uses max_rx_pkt_len for scattering > > > > > > ena > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D adapter->max_mtu > > > start() checks max_rx_pkt_len boundaries > > > > > > enic > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D enic->max_mtu + 14 + 4 > > > > > > fm10k > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D FM10K_MAX_PKT_SIZE (15 * 1024) > > > start() uses max_rx_pkt_len for scattering > > > > > > i40e > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D I40E_FRAME_SIZE_MAX (9728) > > > rx_queue_config() checks max_rx_pkt_len boundaries > > > > > > ixgbe > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D 15872 (9728 for vf) > > > start() writes max_rx_pkt_len to HW for jumbo frames only > > > start() uses max_rx_pkt_len for scattering > > > > > > kni > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D UINT32_MAX > > > > > > liquidio > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D LIO_MAX_RX_PKTLEN (64K) > > > start() checks max_rx_pkt_len boundaries > > > > > > mlx4 > > > configure() uses max_rx_pkt_len for scattering > > > info() returns max_rx_pktlen =3D 65536 > > > > > > mlx5 > > > configure() uses max_rx_pkt_len for scattering > > > info() returns max_rx_pktlen =3D 65536 > > > > > > nfp > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D hw->mtu > > > > > > null > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D (uint32_t)-1 > > > > > > pcap > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D (uint32_t)-1 > > > > > > qede > > > configure() uses max_rx_pkt_len for scattering + internal data > > > info() returns max_rx_pktlen =3D ETH_TX_MAX_NON_LSO_PKT_LEN (9700 > - 4 > > > - 4 > > > - 12 - 8) > > > > > > ring > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D (uint32_t)-1 > > > > > > sfc > > > configure() uses max_rx_pkt_len to set internal data > > > info() returns max_rx_pktlen =3D EFX_MAC_PDU_MAX (9202 + 14 + 4 + 4 + > > > 16) > > > > > > szedata2 > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D (uint32_t)-1 > > > > > > tap > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D ETHER_MAX_VLAN_FRAME_LEN (1518 + > 4) > > > > > > thunderx > > > configure() uses max_rx_pkt_len for scattering + sets internal mtu > > > info() returns max_rx_pktlen =3D NIC_HW_MAX_FRS (9200) > > > > > > vhost > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D (uint32_t)-1 > > > > > > virtio > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D VIRTIO_MAX_RX_PKTLEN (9728U) > > > > > > vmxnet3 > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D 16384; > > > > > > xenvirt > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen =3D 2048 > > > > > > > > > Regards, > > > Andriy > > > > > > > > > > > >=20 >=20 >=20 >=20