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
=0A=0A=0A=0A________________________________=0A From: Luigi Rizzo <rizzo@ie= t.unipi.it>=0ATo: Barney Cordoba <barney_cordoba@yahoo.com> =0ACc: "freebsd= -net@freebsd.org" <freebsd-net@freebsd.org>; Adrian Chadd <adrian@freebsd.o= rg> =0ASent: Sunday, August 18, 2013 5:16 PM=0ASubject: Re: it's the output= , not ack coalescing (Re: TSO and FreeBSD vs Linux)=0A =0A=0AOn Sun, Aug 18= , 2013 at 11:01 PM, Barney Cordoba=0A<barney_cordoba@yahoo.com>wrote:=0A=0A= > That's fine, it's a test tool, not a solution. It just seems that it gets= =0A> pushed as if it's some sort of real=0A> world solution, which it's not= . The idea that bringing packets into user=0A> space to forward them rather= =0A> than just replacing the bridge module with something more efficient is= =0A> just silliness.=0A>=0A=0Ayou might want to have a look at the VALE swi= tch=0A=0Ahttp://info.iet.unipi.it/~luigi/vale/=0A=0Athe upcoming version ca= n attach physical interfaces to the switch and keep=0Aall the processing wi= thin the kernel.=0A=0A=0A> If "pushing packets" was a useful task, the solu= tion would be easy.=0A> Unfortunately you need to do=0A> something useful w= ith the packets in between.=0A>=0A>=0Athere are different definitions of wh= at is "useful":=0Asources, sinks, forwarding, dropping (anti DoS), logging,= ids,=0Aare all useful for different people. The mistake, i think,=0Ais to = expect that there is one magic solution to handle all the useful=0Acases.= =0A=0Acheers=0Aluigi=0A_______________________________________________=0A= =0A=0A=0ANobody claimed that there was a magic solution. But when so much t= ime and brainpower=0Ais spent working on kludges (instead of doing things t= hat have mainstream usefulness), it=0Aresults in either 1) fewer people usi= ng it or 2) the kludges become accepted solutions, simply=0Abecause someone= did it. Polling, dummynet, netgraph, flowtable and buf_ring=0Aare all good= examples.=A0=0A=0AIt's the big negative of open source, particularly for t= he bigger projects. Once someone has=0Adone "something", it not worth the e= ffort in most cases to do it in a more correct way; and=A0=0Athe something = becomes all that's available.=0A=0ABC 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>