From owner-freebsd-current@FreeBSD.ORG  Tue Nov 11 22:01:28 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id 90C93D22;
 Tue, 11 Nov 2014 22:01:28 +0000 (UTC)
Received: from host64.kissl.de (host64.kissl.de [213.239.241.64])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (Client CN "*.shmhost.net",
 Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified))
 by mx1.freebsd.org (Postfix) with ESMTPS id 4C192387;
 Tue, 11 Nov 2014 22:01:28 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1])
 by host64.kissl.de (Postfix) with ESMTP id 7C31FB00B09;
 Tue, 11 Nov 2014 23:01:26 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at host64.kissl.de
Received: from host64.kissl.de ([127.0.0.1])
 by localhost (host64.kissl.de [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 7PK-bzg4HoLF; Tue, 11 Nov 2014 23:01:26 +0100 (CET)
Received: from [192.168.0.11] (unknown [95.91.254.245])
 (Authenticated sender: web104p1)
 by host64.kissl.de (Postfix) with ESMTPSA id 2BC4FB00B07;
 Tue, 11 Nov 2014 23:01:26 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: netmap: extension to store user data per packet/slot?
From: Franco Fichtner <franco@lastsummer.de>
In-Reply-To: <CAJ-VmomLyE5to3hYDmhW+32j7UWo0fATPBxOTCiOfpCPytNcTQ@mail.gmail.com>
Date: Tue, 11 Nov 2014 23:01:24 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <C8510DF9-8F18-4E8F-AE6B-365EAE39CA33@lastsummer.de>
References: <560E07EA-2506-487E-88DD-E2B9F7ED9792@lastsummer.de>
 <CAJ-Vmo=1XxdXNOBYR=_iXP-wEgNzYcBuy43TAE32O_5TnZ+T-w@mail.gmail.com>
 <E4CF1489-B259-4ECE-9FFA-FD3850AE1DEC@lastsummer.de>
 <CAJ-VmomLyE5to3hYDmhW+32j7UWo0fATPBxOTCiOfpCPytNcTQ@mail.gmail.com>
To: Adrian Chadd <adrian@freebsd.org>
X-Mailer: Apple Mail (2.1878.6)
Cc: freebsd-current <freebsd-current@freebsd.org>,
 Luigi Rizzo <rizzo@iet.unipi.it>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.18-1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
 <freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>, 
 <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
 <mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Nov 2014 22:01:28 -0000


On 11 Nov 2014, at 22:48, Adrian Chadd <adrian@freebsd.org> wrote:

> Ah, I see. You're missing some unique identifier for each netmap
> buffer. I thought there was one already. Silly me.

Exactly, and, no, thank you for making clear what is needed.  :)

A little more on this: I think struct netmap_slot is convenient
due to the fact that in zero-copy one wouldn't want to mess with
the actual buffer for speed and userland code already touches slot
internals for each ring transition so there is no performance
degradation.

The key benefit is that if userland can use this storage freely
netmap(4) doesn't get in the way of building complex setups that
require decoupled logic and each ring "hop" may alter the state
as required.


Cheers,
Franco