From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 105B7B3B4 for ; Tue, 12 Aug 2014 10:52:45 +0200 (CEST) Received: by mail-wg0-f47.google.com with SMTP id b13so9546144wgh.18 for ; Tue, 12 Aug 2014 01:55:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xCK/OyE+z+5DNAbH+w6anv6G0DzqCIpn6bDroWnbs5c=; b=HDKpWoST7Ld58B/dYHBhLIs9hlB/NnuiPjBt/qjK+c4h9MeZ14QtA0eEhFeDlikqGC 94+WqIxgxktN1PVUie230yu0mTh+vR0X1DxqZwpo7Wqlu2nh/u1mfCcCXlORM3WEqFDw sreBno5PFwnNjzhL8uK8o16al4x8WO98yS7TCGZQVa2Nf8ZjygqspsB19Y6bYMTCxKCW Qz/84VfxZsDzXqrdH+tEH1ZVR7kViQ3XhQVJJ3CRpE6/R42Dm0iiorjczcS6edpyNXtE 6g9LgV0fXLEryE1bLmP7q/184cRTi+RRMPABxY4UgPXN+9vRAEFRt0+wbTaUYSAJZ6H0 ZkoQ== X-Gm-Message-State: ALoCoQnw/i8a10muFtUOhBWTcUvLTrkLq0yvd9HbA3U9G/rxO1NlEzI0yXJvFd58rhRslAeHE+cs X-Received: by 10.194.184.101 with SMTP id et5mr3107926wjc.14.1407833739689; Tue, 12 Aug 2014 01:55:39 -0700 (PDT) Received: from [10.16.0.195] (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by mx.google.com with ESMTPSA id kw1sm7772275wjb.19.2014.08.12.01.55.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Aug 2014 01:55:38 -0700 (PDT) Message-ID: <53E9D689.8010901@6wind.com> Date: Tue, 12 Aug 2014 10:55:37 +0200 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: Bruce Richardson References: <1407789890-17355-1-git-send-email-bruce.richardson@intel.com> <1407789890-17355-5-git-send-email-bruce.richardson@intel.com> In-Reply-To: <1407789890-17355-5-git-send-email-bruce.richardson@intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dev Subject: Re: [dpdk-dev] [RFC PATCH 04/14] mbuf: replace data pointer by an offset X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 08:52:45 -0000 Hi Bruce, On 08/11/2014 10:44 PM, Bruce Richardson wrote: > From: Olivier Matz > > Original patch: > The mbuf structure already contains a pointer to the beginning of the > buffer (m->buf_addr). It is not needed to use 8 bytes again to store > another pointer to the beginning of the data. > > Using a 16 bits unsigned integer is enough as we know that a mbuf is > never longer than 64KB. We gain 6 bytes in the structure thanks to > this modification. > > Signed-off-by: Olivier Matz > > This version: > * Updated original patch to apply to latest on mainline. > * Disabled vector PMD in config as it relies heavily on the mbuf layout > > Signed-off-by: Bruce Richardson Remaining references shown by: git grep "\(pkt->data[^_]\)\|\(mb->data[^_]\)\|\(m->data[^_]\)\|\(mbuf->data[^_]\)" In: app/test-pmd/ieee1588fwd.c examples/vhost_xen/main.c lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c lib/librte_pmd_pcap/rte_eth_pcap.c lib/librte_pmd_xenvirt/rte_eth_xenvirt.c > --- a/lib/librte_mbuf/rte_mbuf.h > +++ b/lib/librte_mbuf/rte_mbuf.h > @@ -140,6 +140,13 @@ struct rte_mbuf { > void *buf_addr; /**< Virtual address of segment buffer. */ > phys_addr_t buf_physaddr; /**< Physical address of segment buffer. */ > uint16_t buf_len; /**< Length of segment buffer. */ > + > + /* valid for any segment */ > + struct rte_mbuf *next; /**< Next segment of scattered packet. */ > + uint16_t data_off; > + uint16_t data_len; /**< Amount of data in segment buffer. */ > + uint32_t pkt_len; /**< Total pkt len: sum of all segments. */ > + > #ifdef RTE_MBUF_REFCNT > /** > * 16-bit Reference counter. > @@ -156,18 +163,12 @@ struct rte_mbuf { > #else > uint16_t refcnt_reserved; /**< Do not use this field */ > #endif > - uint16_t reserved; /**< Unused field. Required for padding. */ > - uint16_t ol_flags; /**< Offload features. */ > - > - /* valid for any segment */ > - struct rte_mbuf *next; /**< Next segment of scattered packet. */ > - void* data; /**< Start address of data in segment buffer. */ > - uint16_t data_len; /**< Amount of data in segment buffer. */ > > /* these fields are valid for first segment only */ > uint8_t nb_segs; /**< Number of segments. */ > uint8_t in_port; /**< Input port. */ > - uint32_t pkt_len; /**< Total pkt len: sum of all segment data_len. */ > + uint16_t ol_flags; /**< Offload features. */ > + uint16_t reserved; /**< Unused field. Required for padding. */ I think we should try to keep comments aligned if possible. > > /* offload features, valid for first segment only */ > union rte_vlan_macip vlan_macip; > @@ -185,7 +186,7 @@ struct rte_mbuf { > uint16_t metadata16[0]; > uint32_t metadata32[0]; > uint64_t metadata64[0]; > - }; > + } __rte_cache_aligned; > } __rte_cache_aligned; > In my initial patch, there was a "reserved2" field at the end of the rte_mbuf structure to keep its size to 64 bytes. This is not really required because of the __rte_cache_aligned, but I wonder if it's a problem to have metadata not starting on a cache line. There can be some conflicts if some part of the code use *(uint32 *)(m + 1) and other part of code m->metadata32[0]. By the way (that's completely off-topic), but I don't really see why having this metadata at the end of mbuf structure is useful. > @@ -1523,7 +1523,8 @@ ixgbe_recv_scattered_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, > } > > /* Prefetch data of first segment, if configured to do so. */ > - rte_packet_prefetch(first_seg->data); > + rte_packet_prefetch((char *)first_seg->buf_addr + > + first_seg->data_off); > It seems there is a trailing whitespace here after the "+" (seen by "git am"). Regards, Olivier