From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f44.google.com (mail-pg0-f44.google.com [74.125.83.44]) by dpdk.org (Postfix) with ESMTP id E3886F72 for ; Fri, 18 Nov 2016 18:43:52 +0100 (CET) Received: by mail-pg0-f44.google.com with SMTP id p66so105069090pga.2 for ; Fri, 18 Nov 2016 09:43:52 -0800 (PST) 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=N+Inn4bGbm7uSoczEraSj4UGkD9eFgIKEYukfAyBuEs=; b=Zkm0eP0dUYvNPvN5MZL6/YoD6UqhF6KLC05ccddHW+G0qazzzQRgYI1ug3c8wZ0HOd e5y0b9S22x14dxcEoDQ52+vOGV0T8/wh7Gv8pl1R4E+wH46ybdIqKfYnsRtVs3NgbWK+ X5c3Vt5ptObvXRIoxAl4ASpywkMmi6oALRTP01gYhFiZiAKqhH3uRrg75EfOmsBBZgD/ jag0Sqg7+YZ0llDCvcjKwQgrp0P+d7wz8EJp1qfGVOeVrIAASeQROxLFLHrLBxDatlyP kmKK/BKNpJZPxW9W8OZWMA6kUJWDcm9Q2ceERSK9zcy8Iz6wiHjkkonvrhm8/lQcAfz4 Wl9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=N+Inn4bGbm7uSoczEraSj4UGkD9eFgIKEYukfAyBuEs=; b=nD+0cQplo9lVaX5+HAOWS6AuP+gDk9ABJ5jH2oxnaPO2fPgk/1jEazNYlHwGgWMvOn jfBEclLD30K8MPMWFNzp37gFrQlp7PQjP4r42ddnQQ1skAYm9LV6wmTZlZJsnFJa0O4S f/QHj6AQXD1oXly4xhjs6z+NtXxE2hQN1Dy7JLoZs0eozLqil5QFPXaAMQZQ2PI1b7G4 VQJnPGSDimb3qeOBaEiUUR6kfAWdhl3pslPW6KmT420+xvCacZKSYMSOo9xEWZmEvmhC XyJ2N75WFatwQUy/OuHIQhXhXRi2jMzcwuF8f5EazdQVQJBI8GrrV3Bc9lnx4DkD5A39 huJw== X-Gm-Message-State: AKaTC00xeB/hBrkJ8yGONKeMlzN7ArYah9hhoqLJL/bIObmqo7EaofgYdeRtgQRzkO5W6w== X-Received: by 10.98.156.17 with SMTP id f17mr1166978pfe.63.1479491032133; Fri, 18 Nov 2016 09:43:52 -0800 (PST) Received: from samsung9 (204-195-68-67.wavecable.com. [204.195.68.67]) by smtp.gmail.com with ESMTPSA id 24sm19447086pfh.41.2016.11.18.09.43.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Nov 2016 09:43:51 -0800 (PST) Date: Fri, 18 Nov 2016 09:43:49 -0800 From: Stephen Hemminger To: Mike Playle Cc: Message-ID: <20161118094349.29c0361c@samsung9> In-Reply-To: References: X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-users] Compatibly adding metadata to mbufs? X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 17:43:53 -0000 On Fri, 18 Nov 2016 16:46:29 +0000 Mike Playle wrote: > Hello, > > I've recently started looking into DPDK. > > We're interested in adding our own metadata to DPDK's mbuf structures > by setting the 'priv_size' parameter to rte_pktmbuf_pool_create(). An > example application which does this is Open vSwitch, and we would like > to do something similar. > > When initialising a PMD, rte_eth_rx_queue_setup() takes a pointer to a > mempool which is used to allocate receive buffers; packets returned > from rte_eth_rx_burst() will be stored in mbufs allocated from this > pool. This means that we can easily alter their layout to add our own > metadata region. > > However it's not clear that this will work in all cases. For instance, > the "rings-based" PMD doesn't appear to work like this. Instead the > sender's mbufs are passed directly to the receiver. This means that if > we connect to Open vSwitch instead of a physical NIC, we will have no > control over the layout of the mbufs we receive, and so we can't > guarantee to be able to store our metadata. > > Conversely, any mbufs that we send back to Open vSwitch will have to > be allocated from its pool rather than ours, otherwise it will be > unable to store its own metadata. > > Do we have to copy the packet data to/from our own mbufs to ensure > compatibility here? We'd like to avoid copies as far as possible. > > Or am I misunderstanding something about how metadata works? > > Regards, > > Mike Playle > Solarflare Communications Don't overload mbuf with metadata. It guarantees that you won't be able to stay current with upstream, and use distro packages. Standard practice is to use the prepend area in the mbuf. Look at FD.io project and some of the examples