From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH] mbuf: add helpers to prefetch mbuf Date: Mon, 09 May 2016 19:28:30 +0200 Message-ID: <4117859.zS18yWBYLJ@xps13> References: <1462810707-7434-1-git-send-email-olivier.matz@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org To: Olivier Matz Return-path: Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by dpdk.org (Postfix) with ESMTP id B7D646CCA for ; Mon, 9 May 2016 19:28:32 +0200 (CEST) Received: by mail-wm0-f53.google.com with SMTP id n129so147236453wmn.1 for ; Mon, 09 May 2016 10:28:32 -0700 (PDT) In-Reply-To: <1462810707-7434-1-git-send-email-olivier.matz@6wind.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2016-05-09 18:18, Olivier Matz: > +/** > + * Prefetch the second part of the mbuf > + * > + * The next 64 bytes of the mbuf corresponds to fields that are used in the > + * transmit path. If the cache line of the architecture is higher than 64B, > + * this function does nothing as it is expected that the full mbuf is > + * already in cache. > + * > + * @param m > + * The pointer to the mbuf. > + */ > +static inline void > +rte_mbuf_prefetch_part1(struct rte_mbuf *m) It is not so natural to call rte_mbuf_prefetch_part1() for the second part. Why not start mbuf parts numbering at 1?