From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 14:34:18 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78BB14DD for ; Thu, 8 Nov 2012 14:34:18 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id C95208FC19 for ; Thu, 8 Nov 2012 14:34:17 +0000 (UTC) Received: (qmail 66037 invoked from network); 8 Nov 2012 16:09:22 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Nov 2012 16:09:22 -0000 Message-ID: <509BC2E2.4030907@freebsd.org> Date: Thu, 08 Nov 2012 15:34:10 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: svn commit: r242739 - stable/9/sys/dev/ti References: <201211080206.qA826RiN054539@svn.freebsd.org> <20121108023858.GA3127@michelle.cdnetworks.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, FreeBSD Net , Pyun YongHyeon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Nov 2012 14:34:18 -0000 On 08.11.2012 05:53, Adrian Chadd wrote: > On 7 November 2012 18:38, YongHyeon PYUN wrote: >> On Wed, Nov 07, 2012 at 06:15:30PM -0800, Adrian Chadd wrote: >>> If so, may I suggest we perhaps accelerate discussing if_transmit() of >>> multiple frames per call? >> >> Hmm, actually I'm still not a fan of if_transmit() at this moment. >> Honestly I don't have good queuing code in driver to handle queue >> full condition. Interactions with altq(9) is also one of my >> concern as well as packet reordering issue of drbr(9) interface. >> -snip- > > I have a vague idea of making if_transmit() as an interface be able to > send multiple frames at once - so the TCP/UDP code could generate all > the fragments and fire them off at once to the NIC. This should fix > your issue and begin allowing devices to take advantage of > multiple-dispatch rather than one if_transmit() call at a time. TCP/UDP doesn't (want to) generate any fragments at all and tries to avoid it at almost all cost. We want to send very large packets and have the NIC fragment/segment it (TSO/UDP frag offload). > We could create a device or interface flag that indicates whether the > driver can handle multiple mbufs chained via m_nextpkt through > if_transmit(), and then teach one or two drivers that particular > logic. Agreed. I think that's the way to go. It must be very well specified in semantics though. Otherwise it's just too easy to leak mbuf all over the place. -- Andre