From owner-svn-src-all@FreeBSD.ORG Thu Nov 1 02:07:13 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C939E8E; Thu, 1 Nov 2012 02:07:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id CE2078FC08; Thu, 1 Nov 2012 02:07:12 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so1488203pbb.13 for ; Wed, 31 Oct 2012 19:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=rV9Cfkoy8qDnUCZlfvU00t2P+dN5WawOpw6ukIGcFgU=; b=G7Bqfjo94UWuJ3tJ6TZILsO+AdmKiHZTijjsiZb56Fvd3aDBVokYLEK3wkw81tlYo9 4WOD8U9f8ET7n+KRNBdXiKgJOX62AHMBa9Y+qLpz6xSoWC6pgyqRj+Q1XMFdJ5aHFBhI ay3VK9hufhuZJNBuY7xB1hYyCnV5mJ6qaQ7bkHnftQypRrPmlw+WJtPG5U60SFl/qXEe i4Cb+FsuhBYnD/QRnudf6Q24LzZUXCs4T+y+S1JjyX0BSRl5AmKeq6mzVkX9SwByvTqg aBPKHtBmiVhiRZDtWoT5bKTO8biClP7DN4hia+DOGW/qYeAxUGPhYJyK+fVDOCF9m7fK MtZw== Received: by 10.66.78.199 with SMTP id d7mr107205323pax.77.1351735631989; Wed, 31 Oct 2012 19:07:11 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id jw14sm3181162pbb.36.2012.10.31.19.07.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Oct 2012 19:07:10 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 01 Nov 2012 11:06:41 +0900 From: YongHyeon PYUN Date: Thu, 1 Nov 2012 11:06:41 +0900 To: Andre Oppermann Subject: Re: svn commit: r242161 - in head/sys: net netinet netpfil/pf Message-ID: <20121101020641.GC3154@michelle.cdnetworks.com> References: <201210262106.q9QL6YgY000943@svn.freebsd.org> <508BBE6C.7010409@freebsd.org> <20121027220137.GJ70741@FreeBSD.org> <20121029204104.GA1431@michelle.cdnetworks.com> <20121029052100.GO70741@FreeBSD.org> <20121029214038.GD1431@michelle.cdnetworks.com> <508E3C6B.2090102@freebsd.org> <20121030022507.GB4298@michelle.cdnetworks.com> <5090DA4A.5090502@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5090DA4A.5090502@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Gleb Smirnoff , src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 02:07:13 -0000 On Wed, Oct 31, 2012 at 08:59:06AM +0100, Andre Oppermann wrote: > On 30.10.2012 03:25, YongHyeon PYUN wrote: > >On Mon, Oct 29, 2012 at 09:20:59AM +0100, Andre Oppermann wrote: > >>On 29.10.2012 22:40, YongHyeon PYUN wrote: > >>>On Mon, Oct 29, 2012 at 09:21:00AM +0400, Gleb Smirnoff wrote: > >>>>On Mon, Oct 29, 2012 at 01:41:04PM -0700, YongHyeon PYUN wrote: > >>>>Y> On Sun, Oct 28, 2012 at 02:01:37AM +0400, Gleb Smirnoff wrote: > >>>>Y> > On Sat, Oct 27, 2012 at 12:58:52PM +0200, Andre Oppermann wrote: > >>>>Y> > A> On 26.10.2012 23:06, Gleb Smirnoff wrote: > >>>>Y> > A> > Author: glebius > >>>>Y> > A> > Date: Fri Oct 26 21:06:33 2012 > >>>>Y> > A> > New Revision: 242161 > >>>>Y> > A> > URL: http://svn.freebsd.org/changeset/base/242161 > >>>>Y> > A> > > >>>>Y> > A> > Log: > >>>>Y> > A> > o Remove last argument to ip_fragment(), and obtain all > >>>>needed information > >>>>Y> > A> > on checksums directly from mbuf flags. This simplifies > >>>>code. > >>>>Y> > A> > o Clear CSUM_IP from the mbuf in ip_fragment() if we did > >>>>checksums in > >>>>Y> > >>>>Y> I'm not sure whether ti(4)'s checksum offloading for IP fragmented > >>>>Y> packets(CSUM_IP_FRAGS) still works after this change. ti(4) > >>>>Y> requires CSUM_IP should be set for IP fragmented packets. Not sure > >>>>Y> whether it's a bug or not. I have a ti(4) controller but I don't > >>>>Y> remember where I can find it and don't have a link > >>>>Y> parter(1000baseSX) to test it. :-( > >>>> > >>>>ti(4) declares both CSUM_IP and CSUM_IP_FRAGS, so ip_fragment() won't do > >>> > >>>Because it supports both CSUM_IP and CSUM_IP_FRAGS. Probably ti(4) > >>>is the only controller that supports TCP/UDP checksum offloading > >>>for an IP fragmented packet. > >> > >>This is a bit weird if it doesn't do the fragmentation itself. > >>Computing the IP header checksum doesn't differ for normal and > >>fragmented packets. The protocol checksum (TCP or UDP) stays > >>the same for in the case of IP level fragmentation. It is only > >>visible in the first fragment which includes the protocol header. > > > >My interpretation for CSUM_IP_FRAGS works like the following. > > - Only peuso header checksum for TCP/UDP is computed by upper > > stack. > > - Controller has no ability to fragment the packet so it should > > done in upper stack(i.e. ip_output()). > > - When ip_output() has to fragment the packet, it just fragments > > the packet without completing TCP/UDP and IP checksum. If > > controller does not support CSUM_IP_FRAGS feature, ip_output() > > can't delay TCP/UDP checksum in this stage. > > - The fragmented packets are sent to driver. Driver sets > > appropriate bits of DMA descriptor based on fragmentation field > > of mbuf(M_FRAG, M_LASTFRAG) and issue the frame to controller. > > - The firmware of controller queues the fragmented frames up in > > its internal memory and hold off sending out the frames since it > > has to compute TCP/UDP checksum. When it sees a frame which > > indicates the end of fragmented frame it finally computes > > TCP/UDP checksum and send each frame out to wire by computing > > IP checksum on the fly. > >The difference is which one(upper stack vs. controller) computes > >TCP/UDP/IP checksum. > > Such a behavior doesn't make much sense and probably wasn't used at all > in practice. It's very complex as well. Plus you can't guarantee that It's job of firmware running on embedded MIPS R4000 in the controller. ti(4) was one of the best smart controller in the past and it even supported header split! > there won't be other packet slipping into the interface queue in an SMP > world. > Hmm, right, I should have noticed that after FreeBSD's removal for splnet()/splimp(). Since ti(4) is the only controller that supports TCP/UDP checksum offloading on IP fragmented packets and it's rare to see ti(4) controllers in these days, I think there is no much point to make the hardware feature work. I'll remove the feature in ti(4).