From owner-freebsd-net@freebsd.org Thu Nov 17 23:27:00 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA523C47B5A for ; Thu, 17 Nov 2016 23:27:00 +0000 (UTC) (envelope-from dreadiscool@gmail.com) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A4F4FF31 for ; Thu, 17 Nov 2016 23:27:00 +0000 (UTC) (envelope-from dreadiscool@gmail.com) Received: by mail-qk0-x22e.google.com with SMTP id n21so242800756qka.3 for ; Thu, 17 Nov 2016 15:27:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y540od+JukRoc697gF9miNPzD6tFpgYeYCgV7/IDxm4=; b=nt18jgMgP8l5bRe51uSDtGEujr8cF9gLSedHmzUz3Zk1DiFUoEWrqpa+ygMdaeKi/p +83yDsgSQ+LgWS6j3LIeizfCFci0JCSf02mnsnmoeE1cywIgwuRL+ug/DrmR6HtwuqlL /koylpTBCTYbWxuqG37lV35BTrAHI1+Ey5U4p1ul+OaN/8wOEt0RmXRsi3x4QTKgpQ7w Z/xIzHC5rGJ0CeFQ6wOtCDagVEJOG3qbKWSENbeLQc+HTJlqLZSmTnx5S7q2UZdnEWtr C0uQOmgMKltAGwXHFVIGSzpCVFxu/Hyn+Iz50+LTjNDDvDrFKUqky6Nsj68w0lvXapmZ +edA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y540od+JukRoc697gF9miNPzD6tFpgYeYCgV7/IDxm4=; b=DQUFAsbdulqiQi4rshYLlT2eU0s62bqOCGm7I+Ikvbn3nPpRtZ6pLkDmlCyr7aaQRM vZ/ocs1VK8pyjPFYPiKWdyQ3jWg7NyXvWtIHVAlUJuyBS/YNWdhpgGKtrDAGYXV4CeCB u+lYlwc0k9VJWQGZ0xGw8nl8JMm4M4IWYl5sKMv/I++SJkMrW8XUnfovTX6JjLWvfSa8 1JxpMtamx+9pxmvJONC9UqCWuTgSIk27xea/gEMqAMdlfpZn0PNuii2G/QN5MT+Svg/F G6TBrBIeZQeBaZ0Ao7+yg6A8a1NlRsV1SNZZ2dbyETlI+G5rsaWJdGzQiuU2r3Ir9gCm j+pg== X-Gm-Message-State: AKaTC020GfnP31HMiK1AvLsf4ldATJrjGXuLdAJaW5ITi50/c7wyTO+K7s1vlGnioIfzQJ8vEK29EwPltaeqYg== X-Received: by 10.55.36.149 with SMTP id k21mr6738287qkk.252.1479425219809; Thu, 17 Nov 2016 15:26:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.144.144 with HTTP; Thu, 17 Nov 2016 15:26:59 -0800 (PST) In-Reply-To: References: From: Paras Jha Date: Thu, 17 Nov 2016 18:26:59 -0500 Message-ID: Subject: Re: Advantages of Netmap NM_OPEN_NO_MMAP To: Vincenzo Maffione Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 23:27:01 -0000 Hi, Thanks for the quick reply, it clarified things for me. Regarding the idea of independent TX-RX ring couples per thread, would a possible variation of this methodology be 1 RX ring per interface (only one thread reads), but *x* amount of TX rings, where *x *is the number of threads. Am I correct in assuming that such a structure will allow lockless zero-copy between an arbitrary number of interfaces (3 or greater)? Regards On Thu, Nov 17, 2016 at 5:11 PM, Vincenzo Maffione wrote: > Hi, > No, each interface open in netmap mode has its own netmap buffers (for > packet data) and netmap rings, independently of what is the netmap memory > region where buffers/rings resides. > Two applications using different interfaces can work independently on each > other (no locks needed), it does not matter whether they are in the same > netmap memory region or not, because the data structures (rings and > buffers) are separated. > It does matter in terms of isolation, of course: two applications using > the same shared memory must trust each other. > > Typically you want two interfaces to be in the same netmap memory region > because you want an application to do zerocopy packet forwarding between > the two interfaces. > Also in this case locks are not usually needed, since you would have a > single thread accessing both interfaces. (Or you could have a separate > thread for each TX-RX ring couple, but always without using locks.) > > You can imagine a netmap memory region as a pool of buffers and rings, > where one or more interfaces can allocate their buffers/rings when they > enter netmap mode (deallocation is on exit from netmap mode). > Your system can have many memory regions. By default all the physical > interfaces share the same memory region, while each VALE port uses a > private memory region. > This is however being changed to ease arbitrary association between > interfaces and memory regions. > > Cheers, > Vincenzo > > 2016-11-17 22:50 GMT+01:00 Paras Jha : > >> Hi all, >> >> I had a quick question about some of the implications of sharing packet >> buffer memory between multiple interfaces. Assuming an arbitrary amount of >> interfaces (> 2) are linked together with NM_OPEN_NO_MMAP and share the >> same memory, would this have any issues with lock contention? >> >> Sorry in advance if this is the wrong place to post, I had seen several >> other archives about Netmap on this mailing list and I thought it was the >> most appropriate place. >> >> Regards >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > > -- > Vincenzo Maffione >