Date: Mon, 19 Aug 2013 09:16:01 -0700 (PDT) From: Barney Cordoba <barney_cordoba@yahoo.com> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) Message-ID: <1376928961.25340.YahooMailNeo@web121602.mail.ne1.yahoo.com> In-Reply-To: <CA%2BhQ2%2Bips=QUeyK3bwMQhc8yPavMzd3i-3YDjksy4hEVNBR%2BXA@mail.gmail.com> References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <1376745244.6575.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1376748170.66110.YahooMailNeo@web121601.mail.ne1.yahoo.com> <CAJ-VmonGeqn5qqbfvF9xWaFPYNMNSVb6VwMx%2BoEVSGXVid98ag@mail.gmail.com> <1376833738.94737.YahooMailNeo@web121605.mail.ne1.yahoo.com> <71EA3DFB-B410-432D-98E0-B6341556BE6D@netgate.com> <CAJ-Vmo=0OX=_6cO_pZ45XrvfQzb%2BNVms00LUo5oRriZWUMBx%2Bg@mail.gmail.com> <1376851152.3322.YahooMailNeo@web121606.mail.ne1.yahoo.com> <CAJ-VmokPhxAe1CAVqfKDJhssqg0VaUZT4hRPNB9gigECebh7VA@mail.gmail.com> <1376859717.20232.YahooMailNeo@web121605.mail.ne1.yahoo.com> <CA%2BhQ2%2Bips=QUeyK3bwMQhc8yPavMzd3i-3YDjksy4hEVNBR%2BXA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
________________________________ From: Luigi Rizzo <rizzo@iet.unipi.it> To: Barney Cordoba <barney_cordoba@yahoo.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>; Adrian Chadd <adrian@freebsd.org> Sent: Sunday, August 18, 2013 5:16 PM Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) On Sun, Aug 18, 2013 at 11:01 PM, Barney Cordoba <barney_cordoba@yahoo.com>wrote: > That's fine, it's a test tool, not a solution. It just seems that it gets > pushed as if it's some sort of real > world solution, which it's not. The idea that bringing packets into user > space to forward them rather > than just replacing the bridge module with something more efficient is > just silliness. > you might want to have a look at the VALE switch http://info.iet.unipi.it/~luigi/vale/ the upcoming version can attach physical interfaces to the switch and keep all the processing within the kernel. > If "pushing packets" was a useful task, the solution would be easy. > Unfortunately you need to do > something useful with the packets in between. > > there are different definitions of what is "useful": sources, sinks, forwarding, dropping (anti DoS), logging, ids, are all useful for different people. The mistake, i think, is to expect that there is one magic solution to handle all the useful cases. cheers luigi _______________________________________________ Nobody claimed that there was a magic solution. But when so much time and brainpower is spent working on kludges (instead of doing things that have mainstream usefulness), it results in either 1) fewer people using it or 2) the kludges become accepted solutions, simply because someone did it. Polling, dummynet, netgraph, flowtable and buf_ring are all good examples. It's the big negative of open source, particularly for the bigger projects. Once someone has done "something", it not worth the effort in most cases to do it in a more correct way; and the something becomes all that's available. BC From owner-freebsd-net@FreeBSD.ORG Mon Aug 19 22:38:18 2013 Return-Path: <owner-freebsd-net@FreeBSD.ORG> Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7D622CDB; Mon, 19 Aug 2013 22:38:18 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id 3B1252D71; Mon, 19 Aug 2013 22:38:17 +0000 (UTC) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTPS id 81EF611E4C; Tue, 20 Aug 2013 08:38:16 +1000 (EST) Received: from Peter-Grehans-MacBook-Pro-2.local ([64.245.0.210]) by dommail.onthenet.com.au (MOS 4.2.4-GA) with ESMTP id BOB63025 (AUTH peterg@ptree32.com.au); Tue, 20 Aug 2013 08:38:15 +1000 Message-ID: <52129E55.30803@freebsd.org> Date: Mon, 19 Aug 2013 15:38:13 -0700 From: Peter Grehan <grehan@freebsd.org> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andre Oppermann <andre@freebsd.org> Subject: M_NOFREE removal (was Re: svn commit: r254520 - in head/sys: kern sys) References: <201308191116.r7JBGsc6065793@svn.freebsd.org> <521256CE.6070706@FreeBSD.org> <5212587A.2080202@freebsd.org> <52128937.1010407@freebsd.org> In-Reply-To: <52128937.1010407@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, freebsd-net@freebsd.org, Navdeep Parhar <np@FreeBSD.org> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>; List-Post: <mailto:freebsd-net@freebsd.org> List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=subscribe> X-List-Received-Date: Mon, 19 Aug 2013 22:38:18 -0000 Hi Andre, (moving to the more appropriate freebsd-net) > I'm sorry for ambushing but this stuff has to be done. I have provided > an alternative way of handling it and I'm happy to help you with your > use case to make it good for you and to prevent the mbuf system from > getting bloated and hackish again. Sure. I'm not really upset since my code wasn't too far along, but with any API, you never know who consumers might be so it's always worth being proactive about announcing it's removal. > Can you please describe your intended use of M_NOFREE to better understand > the shortcomings of the current mbuf systems and the additional advantages > of the M_NOFREE case? I was looking at something similar to Linux's vhost-net, where a guest's virtio ring would be processed in-kernel. An mbuf chain with external buffers would be used to pass guest tx buffer/len segments directly into FreeBSD drivers. The intent of M_NOFREE was to avoid small mbuf allocations/frees in what is a hot path. This code was intended to run at 10/40G. Note this code isn't really generic - it would require interfaces to be 'owned' by the guest, except that direct PCI-level pass-through wouldn't be needed. If there's an alternative to M_NOFREE, I'd be more than happy to use that. later, Peter.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1376928961.25340.YahooMailNeo>