From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f172.google.com (mail-wr0-f172.google.com [209.85.128.172]) by dpdk.org (Postfix) with ESMTP id 6960B326B for ; Wed, 5 Apr 2017 11:37:41 +0200 (CEST) Received: by mail-wr0-f172.google.com with SMTP id w11so5434359wrc.3 for ; Wed, 05 Apr 2017 02:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=DngfTc33qZue0jZa8S8pWdngvM9jalSMMwgRVf90IAQ=; b=leWXztpG2Z9Z8GDUXS0DRjkB6eOJ+GB9OMve5BwWZOmIrOfHPhocxTpUIMPCE3ADnH /cIcUxOD49B9kKS8FQYaVxbwurqx0uCdhykVRYRPbXl3Cp+dyGiWtvJ3pWy9t/PGsK0O eYCTzz2QL27KJt6r2dmwmPo+bk/ApPv0If0az+haoce+JQf1rYhYiWB6wEkuJ76SBIkY vO6E9m71/L2tk876nO5dX5YvrCH05RTR++2FWW8JrxvjkuRwx4TlK7CjMFy4ih5Lw8qa YdhJqtngYE6lMouB0JkoE9lPlgjW2VhA8DzYsvkutJGMywXLCMWmib1i11xMP6DlW/Zq G+dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=DngfTc33qZue0jZa8S8pWdngvM9jalSMMwgRVf90IAQ=; b=s6cqphN0WXPmwryiY5CMRte1CqZqFhyD3meXzeV5V+wBb641ChP1fYL00t8zvN6DYW ziVnxdYHTf2VxlVapZO6ADeQIUykMny9jvzHdUUquf3euivJP9ANrcdzVvyxPCrEf+QS 9Tcq7E5wVysD2tt+49KRBPEAGacEMifP934AKUkV9WSwz1vudc52u/TxS9NYTvDw/BD0 Ik1E16fbdG4PAwUZXs2U0O8VUN3+N7XZcWesseU6MA6wIPhbiyHlUQMIoaKcYgTTdOql zwdVR5q4jb4Q57OA/qxlmvAQGYAgJd6Vq9gJoBDkFG9DXw97gHdGtKSuouo5yATAbnCT FvuA== X-Gm-Message-State: AFeK/H0gm5OhpiTASsik9Bnu/BXFh95+zlUhOYUdnWhaB/VPAXYDGIOS8Tjp2fVYcLhuEa5K X-Received: by 10.223.130.13 with SMTP id 13mr1398450wrb.150.1491385060788; Wed, 05 Apr 2017 02:37:40 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id 46sm25662251wru.37.2017.04.05.02.37.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 02:37:39 -0700 (PDT) From: Thomas Monjalon To: Olivier Matz Cc: dev@dpdk.org, konstantin.ananyev@intel.com, bruce.richardson@intel.com, mb@smartsharesystems.com, andrey.chilikin@intel.com, jblunck@infradead.org, nelio.laranjeiro@6wind.com, arybchenko@solarflare.com, jerin.jacob@caviumnetworks.com Date: Wed, 05 Apr 2017 11:37:39 +0200 Message-ID: <2948467.vjfs1XSdfO@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20170404162807.20157-1-olivier.matz@6wind.com> References: <1488966121-22853-1-git-send-email-olivier.matz@6wind.com> <20170404162807.20157-1-olivier.matz@6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 0/8] mbuf: structure reorganization 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, 05 Apr 2017 09:37:41 -0000 2017-04-04 18:27, Olivier Matz: > Based on discussions done in [1] and in this thread, this patchset reorganizes > the mbuf. > > The main changes are: > - reorder structure to increase vector performance on some non-ia > platforms. > - add a 64bits timestamp field in the 1st cache line. This timestamp > is not normalized, i.e. no unit or time reference is enforced. A > library may be added to do this job in the future. > - m->next, m->nb_segs, and m->refcnt are always initialized for mbufs > in the pool, avoiding the need of setting m->next (located in the > 2nd cache line) in the Rx path for mono-segment packets. > - change port and nb_segs to 16 bits > - move seqn in the 2nd cache line Applied, thanks for the long work We need to add a patch to bump ABIVER and document the changes. > Things discussed but not done in the patchset: > - move refcnt and nb_segs to the 2nd cache line: many drivers sets > them in the Rx path, so it could introduce a performance regression, or > it would require to change all the drivers, which is not an easy task. If it is worth to move these fields in 2nd cache line, can we plan to rework drivers for not setting them in Rx? > Once this patchset is pushed, the Rx path of drivers could be optimized a bit, > by removing writes to m->next, m->nb_segs and m->refcnt. The patch 4/8 gives an > idea of what could be done. Yes drivers patches are welcome :) Please target RC2 for these changes.