From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id A6042A04C5; Sat, 5 Sep 2020 19:00:58 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1D0CA2BF1; Sat, 5 Sep 2020 19:00:58 +0200 (CEST) Received: from mail-pj1-f68.google.com (mail-pj1-f68.google.com [209.85.216.68]) by dpdk.org (Postfix) with ESMTP id 49B17A3 for ; Sat, 5 Sep 2020 19:00:56 +0200 (CEST) Received: by mail-pj1-f68.google.com with SMTP id kk9so2081848pjb.2 for ; Sat, 05 Sep 2020 10:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Ezcc8y3HrIifpJlm/nK+zFOuZlHFKQOGHwME4lVfccg=; b=u1xd1AbC33BhvQ8dLGSmz/kxV0DIsY+aeAvqzMaaXp6H7KAhpxS3lM9AUKeVXtwZtB Ol68YD33yZsH/mRKZOs9h7fepPXfUEoif20NfMm/67jNaTjBmrtwBfz3WSO0F/7F4pqF rH2mUjredCIPbV0HihModL3J3J3Syqi5nh75HFL9b5KBpIWkE5FzCXMmodzS03bTWynr SacnUQFkVhfIwhZQd1ZFhuWPbTuPNrzH+PgHgwHm95KampWqzyD10fsFx3Hy5vZrC23C B09GgI/RAmWW8r0bfjACPoXdEZoHYKFFcHlyzCtGLASi2DgwqhH666b60teGe+IXVpiV F0FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Ezcc8y3HrIifpJlm/nK+zFOuZlHFKQOGHwME4lVfccg=; b=SscpNghx6AWrAY+06O6eE/2OgiUMyN5I5qZ5kIMzjlak3lSVKWJx3vmTl9Zd69e2Cw hn6+QG9hZVQpdNBMG+TtmVcJHtPCSSFxKbVz+HS7t0Z6GZ92aID7BVC/U2wmEZcQIDFw 5XKU+81dZi2of4o2Ku/TlmjGBTWlTo7zGO5+WPMOrhQqkd5JrbDSi9S1iLfyiWf5CFkT E9PtxRy07wH8det4v7m6E0SeLCybvOJnEEEzku4MX3TJ8N8Nnml5XtfRSRU7Kpk2REJF gTJ7rx96QFq5ODzwbkO+njK4VK8Kr33e963zm2p2Es+D8ISdtxAnvBNpDMokWV0x1J71 8ISA== X-Gm-Message-State: AOAM532DRI/X5TS1y/2u3zAXmoESTzRb3dRbNjVpS8hqPvFMiSy5QCRf iAs2eJiCyS489aBFm/jg+0E3ig== X-Google-Smtp-Source: ABdhPJyqVCW0wr90mD5F/UMTgWKwdiSHvcpn6BOwO9mlD6L1iaQcefNVYd97j4QoSQ0ifr6YfmAOjg== X-Received: by 2002:a17:902:8690:: with SMTP id g16mr13615725plo.257.1599325255265; Sat, 05 Sep 2020 10:00:55 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id b20sm10856691pfb.198.2020.09.05.10.00.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 05 Sep 2020 10:00:55 -0700 (PDT) Date: Sat, 5 Sep 2020 09:56:27 -0700 From: Stephen Hemminger To: Haiyue Wang Cc: dev@dpdk.org, ferruh.yigit@intel.com, Olivier Matz Message-ID: <20200905095618.0844b4b6@hermes.lan> In-Reply-To: <20200905030646.374157-1-haiyue.wang@intel.com> References: <20200904054020.77648-1-haiyue.wang@intel.com> <20200905030646.374157-1-haiyue.wang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2] net: adjust the header length parse size 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Sat, 5 Sep 2020 11:06:46 +0800 Haiyue Wang wrote: > Align to the rte_mbuf's design about Tx header length data size for the > header length parse result. > struct { > uint64_t l2_len:7; /* 88: 0 8 */ > uint64_t l3_len:9; /* 88: 7 8 */ > uint64_t l4_len:8; /* 88:16 8 */ > uint64_t tso_segsz:16; /* 88:24 8 */ > uint64_t outer_l3_len:9; /* 88:40 8 */ > uint64_t outer_l2_len:7; /* 88:49 8 */ > }; > > Now the IPv6 can support bigger extension header. > > The below is the structure hole analysis result: > > Before: > struct rte_net_hdr_lens { > uint8_t l2_len; /* 0 1 */ > uint8_t l3_len; /* 1 1 */ > uint8_t l4_len; /* 2 1 */ > uint8_t tunnel_len; /* 3 1 */ > uint8_t inner_l2_len; /* 4 1 */ > uint8_t inner_l3_len; /* 5 1 */ > uint8_t inner_l4_len; /* 6 1 */ > > /* size: 7, cachelines: 1, members: 7 */ > /* last cacheline: 7 bytes */ > }; > > Now: > struct rte_net_hdr_lens { > uint64_t l2_len:7; /* 0: 0 8 */ > uint64_t l3_len:9; /* 0: 7 8 */ > uint64_t l4_len:8; /* 0:16 8 */ > uint64_t tunnel_len:8; /* 0:24 8 */ > uint64_t inner_l2_len:7; /* 0:32 8 */ > uint64_t inner_l3_len:9; /* 0:39 8 */ > uint64_t inner_l4_len:8; /* 0:48 8 */ > > /* size: 8, cachelines: 1, members: 7 */ > /* bit_padding: 8 bits */ > /* last cacheline: 8 bytes */ > }; > > Signed-off-by: Haiyue Wang Bitfields are slow to access, compiler has to do mask/shift operations. And there is no requirement that structure be the same size. There is no requirement that fields be ordered the same as the protocol header. Also tunnel length might get big. Why not: struct rte_net_hdr_lens { uint8_t l2_len; uint8_t inner_l2_len; uint16_t l3_len; uint16_t inner_l3_len; uint16_t tunnel_len; uint8_t l4_len; uint8_t inner_l4_len; };