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. > > >>software checksums, and thus won't clear these flags. > >> > >>Potentially a driver that announces one flag in if_hwassist but relies on > >>couple of flags to be set on mbuf is not correct. If a driver can't do > >>single > >>checksum processing independently from others, then it should set or > >>clear > >>appropriate flags in if_hwassist as a group. > > > >Hmm, then what would be best way to achieve CSUM_IP_FRAGS in > >driver? I don't have clear idea how to utilize the hardware > >feature. The stack should tell that the mbuf needs TCP/UDP checksum > >offloading for IP fragmented packet(i.e. CSUM_IP_FRAGS is not set by > >upper stack). > > As I said there can't be fragment checksumming without hardware It's up to controller's firmware. It does not send the fragmented frame until it computes TCP/UDP checksum. > based fragmentation. We have three cases here: > > 1. TSO where the hardware does the segmentation, TCP and IP header > checksums for each generated packet. > 2. IP packet fragmentation where a packet is split, the IP header > checksum is recomputed for each fragment, but the protocol csum > stays the same and is not modified. > 3. UDP fragmentation where a large packet is sent to the hardware > and it generates first the UDP checksum and then splits it into > IP fragments each with its own IP header checksum. > > So we end up with these possible large send hardware offload capabilities: > TSO: including IPv4hdr and TCP checksumming > UDP fragmentation: including IPv4hdr and UDP checksumming > IP fragmentation: including IPv4hdr checksumming > > Besides that we have the packet <= MTU sized offload capabilities: > TCP checksumming > UDP checksumming > SCTP checksumming > IPv4hdr checksumming > > >>Y> > A> > hardware. Some driver may not announce CSUM_IP in theur > >>if_hwassist, > >> ^^^^^^^^ > >> > >>Oh, that was a typo! Software was meant. > > That explains quite a bit of confusion. > > -- > Andre > _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
