svn commit: r242161 - in head/sys: net netinet netpfil/pf

[YongHyeon PYUN]

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).