From owner-freebsd-net@freebsd.org Thu Nov 17 22:11:56 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 22B48C47409 for ; Thu, 17 Nov 2016 22:11:56 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 C48AF1D1F for ; Thu, 17 Nov 2016 22:11:55 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x231.google.com with SMTP id 128so69498237oih.0 for ; Thu, 17 Nov 2016 14:11:55 -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=lMq4l7EV+oZpfILs6tDolpLzm4Xd0bJzIL5wIhi4h9U=; b=jeeyxMR04N99gdB4Uehgs0fQUKi26YREhpFd+0PHJGFYcMzVgre5tNcIFgCYIm6gsT Mm80v2tF0n+Kl8m55i623+rtJxDOYJgxHDyZsE1lUbjkmDIzDlzpT5rPDKXGovdHZVr4 XbcpyU/Y4uMyOFjALp8nnto1V6i3ha1BUPOQIlsta8RfwV9jaToHrObvUSkyqqP9SCn5 Oc40hd3mF75irAj4VFzFzaAOdsWWBTGS+MnRP4Qze81Y9CotYcjq+CsoRfLqO67wSHtH azHXUeNwLZNhVDOUzNdkI4Za+d44a8VMqA4wcVyfye715y37Qt/LGeTxh8TTI5iOCJ2f 22lA== 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=lMq4l7EV+oZpfILs6tDolpLzm4Xd0bJzIL5wIhi4h9U=; b=g7sefy9FcrX1hZHJrjyPR9XlkuAJ/vfM/YrUg+BbUc8fXwZxSQ36n3rmyR0o2qMnbI AFKYAQtcjT6iVTwxtoEUQi5GJsajCnxurtYfYnQB6/5sRXpVl6bjlOPiAokmsgLSb2Vi QLNviZ0Js7vDYK7UYZifa1OPDHfXW90Uy9cQ+of3vUnwWapmjfkoatpvz/aUUISzCrth pgRWG5PS5uQr+wPyLrWnMysXap/AzveYMe7EqWjI9olp3tVh7sOCdnMhy56JjstSgCUP DvowjIQw23SBizxPxH2mjVTB+Oodnc/CQKwgzkR6IMbVhpikC1eDumGF65HCIw1H8CX3 BiNg== X-Gm-Message-State: ABUngvdISG5pI5bBQYsF05jsa3c7Ebkr8WSwvLsqCMVSiyF0z+CSkMQje3FnEqfwdHsqnkEa/770T67eKIBCdw== X-Received: by 10.157.2.36 with SMTP id 33mr2552408otb.180.1479420714985; Thu, 17 Nov 2016 14:11:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.45.134 with HTTP; Thu, 17 Nov 2016 14:11:54 -0800 (PST) In-Reply-To: References: From: Vincenzo Maffione Date: Thu, 17 Nov 2016 23:11:54 +0100 Message-ID: Subject: Re: Advantages of Netmap NM_OPEN_NO_MMAP To: Paras Jha 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 22:11:56 -0000 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