From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 21:41:20 2014 Return-Path: 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 56A6D29D; Tue, 11 Nov 2014 21:41:20 +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 13CFC103; Tue, 11 Nov 2014 21:41:19 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by host64.kissl.de (Postfix) with ESMTP id 8D4B9B00ACF; Tue, 11 Nov 2014 22:41:18 +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 css7IlM5L5vO; Tue, 11 Nov 2014 22:41:18 +0100 (CET) Received: from [192.168.0.11] (unknown [95.91.254.245]) (Authenticated sender: web104p1) by host64.kissl.de (Postfix) with ESMTPSA id 3AF21B00ABD; Tue, 11 Nov 2014 22:41:18 +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 In-Reply-To: Date: Tue, 11 Nov 2014 22:41:16 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <560E07EA-2506-487E-88DD-E2B9F7ED9792@lastsummer.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 21:41:20 -0000 Hi Adrian, On 11 Nov 2014, at 22:22, Adrian Chadd wrote: > ... I'm confused. Do you have the slot id already, right? Why not > allocate an array of userdata pointers somewhere else and just use the > netmap slot id as an indirection into that? The slot id is per ring and there are a lot of them. In case of zero-copy the slot changes at least 1. Consider two processes for the load balancing case. Process 1 attaches to the devices and Process 2 only has a a pipe pair for receiving and sending packets back to Process 1 after processing, because only that process has access to the real devices: em0, em1, etc. <--RX/TX--> Process 1 <--pipe pair--> Process 2 (Hardware) (Balancer) (Worker) There is no way to trace packet origin back to em0 or em1 after pushing the packets through the pipe pair unless either the pipes are unique for each device or there is another means to keep its state. Should, however, the buffer id be unique that would make it easy to do what you suggest, but I don't know the netmap(4) internals by heart. It seems a wee unnatural to rebuild tracing of packets in userland when netmap(4) has all the infrastructure needed to deal with this effectively, but I'm not opposed to doing that to avoid API/ABI changes. Speaking of those, should volatile internals change regarding the buffer id that would also break the attempts to deal with the issue consistently. Cheers, Franco