From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 21:48:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 497664D1 for ; Tue, 11 Nov 2014 21:48:43 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CDF70186 for ; Tue, 11 Nov 2014 21:48:42 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id n3so3002687wiv.8 for ; Tue, 11 Nov 2014 13:48:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=XmLdJi1XDoMk4FTcdNgqrofKNZ0EyzY+RzBx3ltkt5g=; b=kScz5idI3B1VfM+uTTxNXy9oN8n3jxyOTOV6TA1mJyqTRlGkyPWZiofr9FsJ9aTy9u mwQJIZIV+chuUUBeDZ02vyCBGTmvGqREvwJfnwWs8BcETQugoc5ASSmPhsVOgXNBlD21 9+rctAJqoR5zj3nGRQgE2BHZaDOQ+OXwoMVccWf/FZdI7ACYtdAJ1aEsNqqwx50GHiFc JRMEUY1cb/0F5BUiRf3k/rqBmQ2rxQlVp4RbbjtFA5kmq/xy7Prp31VHBehBy/Hmo/fx 7+HHW1Id/6aL7ovGyyyZg+VuLciQTXc4Pq9lcxQEIh4QTW0IqSGKy5+/i/mSUAkhtac+ kjQw== MIME-Version: 1.0 X-Received: by 10.180.73.212 with SMTP id n20mr1032898wiv.59.1415742521376; Tue, 11 Nov 2014 13:48:41 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Tue, 11 Nov 2014 13:48:40 -0800 (PST) In-Reply-To: References: <560E07EA-2506-487E-88DD-E2B9F7ED9792@lastsummer.de> Date: Tue, 11 Nov 2014 13:48:40 -0800 X-Google-Sender-Auth: kKSvXU3aqn5fRCPNxkP2ecN_jmQ Message-ID: Subject: Re: netmap: extension to store user data per packet/slot? From: Adrian Chadd To: Franco Fichtner Content-Type: text/plain; charset=UTF-8 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:48:43 -0000 On 11 November 2014 13:41, Franco Fichtner wrote: > 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. Ah, I see. You're missing some unique identifier for each netmap buffer. I thought there was one already. Silly me. Luigi? -adrian