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 062D2A04A7; Tue, 25 Jan 2022 22:25:17 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B1C6941184; Tue, 25 Jan 2022 22:25:16 +0100 (CET) Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) by mails.dpdk.org (Postfix) with ESMTP id 6761641161 for ; Tue, 25 Jan 2022 22:25:15 +0100 (CET) Received: by mail-pf1-f181.google.com with SMTP id 128so20929374pfe.12 for ; Tue, 25 Jan 2022 13:25:15 -0800 (PST) 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=QIhqYNnIq2DBfrglJWC8/8chLoNDCtSlI0Duc9QV5K8=; b=FnzKQkB24bObuq6MhR6a0bToITPqBjyQfN3UHHa1Q43sjmWilF89190q4GdE3gjz9I 95JubX6biU5aOzYpUfZcI8jv+L0aG54ye8dhh8PHCK9xsaBzWYnxM3Ndgj4u4vkylCgS 7J9T2pMKoguQBv3p5YvRvpQfAgbrWxvHsGHNiaPQeP2qsOtK8ehSdkEE+mij3uYsMxz7 I7CbbPhsSdSyGLHsbshF/mNWXA64W4J3D75jzH8aMSTNvu2X8vKw61enr++s+7ozHLRg XMuFugFeIR16FQL11wyDa8XNheseoADSmjZHyWK3ZLFOPF0/8mxHjzr/E4xlbCSpdVJR O4vA== 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=QIhqYNnIq2DBfrglJWC8/8chLoNDCtSlI0Duc9QV5K8=; b=wCtbwF4t16TmWyY6lp4oEYWjJb6B5wIF2MpifLpDyo20IhTzssq4opuBCSVrxbZYwm r2JxLA2P726EUnx0W6HISkSilmNyOuFY3txjjeN2eapIRpgiOC7EfPWBGPADuXVdfi70 J6zhTC+O37XHYYqWdYBVZfBVtp2MyRVBFOYYaxvIrVpMTyrECJf1P0dv19QfSoeLV0Hx Y8YnMOd0gOR9YpuxrNUMRYSt4YqJiQIdhQaM2fp3MGU5zLdyLNuSSM8paMDCcy6EhtgN T3KrIAI8Nqjj0t19IIRaGLa6qM0DU1FsswVqV8JZgpos5vSzYeUyNt7yaJ7KWdbZaP13 jOLQ== X-Gm-Message-State: AOAM531xH0W9pCd1h6PEzrBK3cXXm5UFozo2MTfYBb01S3YXSd1yaUY5 Gi3WsVvVfJuu6IVhQYCaKOdeMEqusQIp3Q== X-Google-Smtp-Source: ABdhPJwpNlEkjFDnIxCBMdzGWqr2cKhxLi4GhsBywdjVcYKuc+KXoh/LS8IX+4R6agjrixWSXKYIyQ== X-Received: by 2002:a65:6114:: with SMTP id z20mr16856306pgu.124.1643145914448; Tue, 25 Jan 2022 13:25:14 -0800 (PST) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id c8sm22831918pfl.122.2022.01.25.13.25.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Jan 2022 13:25:14 -0800 (PST) Date: Tue, 25 Jan 2022 13:25:11 -0800 From: Stephen Hemminger To: Liron Himi Cc: "dev@dpdk.org" Subject: Re: [EXT] Re: l2/l3_len fields Message-ID: <20220125132511.2f8ba977@hermes.local> In-Reply-To: References: <20220124092104.07db8409@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Tue, 25 Jan 2022 17:38:42 +0000 Liron Himi wrote: > -----Original Message----- > From: Stephen Hemminger > Sent: Monday, 24 January 2022 19:21 > To: Liron Himi > Cc: dev@dpdk.org > Subject: [EXT] Re: l2/l3_len fields > > External Email > > ---------------------------------------------------------------------- > On Mon, 24 Jan 2022 08:39:59 +0000 > Liron Himi wrote: > > > Hi, > > > > > > > > Can you please share the motivation of not filling l2/l3-len fields on PMD's RX function? > > > > PMD already filling the mbuf with parsing info, and the l2/l3-len are also probably part of the HW descriptor, so why no propagate them as well? > > > > The current way for application to find the l2_len (for example) is to examine the ptype using multiple if statement. > > > > However, this may not always work if there are unknown/user headers (e.g. DSA header). > > in addition, some of the examples are not checking the ptype and assumes a specific packet structure. > > e.g. l3-fwd, assumes only ethernet header exist and hardcoded jump by 14B to access the IP header. > > but if VLAN exist it will fail. > > > > checking the l2_len will work in any case. > > > > > > Regards, > > Liron Himi > > > > [A picture containing clipart Description automatically generated] > > > > Park Azorim, Kyriat Arie, Petah Tikva, 49527, Israel > > Mobile: +972.52.3329169 > > > L2 len would be relatively easy since almost all devices are Ethernet only. > L3 len is the problem, many devices don't interpret L3 and below headers. > Only those that have flow type functionality are likely to do that. > > [L.H.] Not sure I understand what you mean. > what will be easy? Easy for the application to calculate the l2_len? > If the hardware doesn't support doing it directly, then if the application needs these it should do the calculations itself. Many chips don't support reporting L2 and L3 lengths in the receive result.