Date: Wed, 18 Jul 2001 08:48:32 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Richard Hodges <rh@matriplex.com> Cc: hackers@FreeBSD.ORG Subject: Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3 Message-ID: <3B55AFD0.65F0C860@mindspring.com> References: <Pine.BSF.4.10.10107171021390.42094-100000@mail.matriplex.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Richard Hodges wrote: > > > Now TX buffers are a problem - I have to take what I get and just > > > "deal with it". If both start address and length need to be aligned, > > > then I'm pretty much screwed - I have to copy... > > > > No, exactly ythe opposite: the TX buffer is _not_ a problem. This > > is because it's assembled from mbuf's, so you can actually put it > > on a 16 byte boundary, and index the mbuf into only the forst 14 > > bytes of the packet for the header. > > It is still a problem. If the hardware requires buffer start and length > to be word aligned, I have to copy the entire mbuf chain if it is not > perfectly aligned to start with. The very rare exception is if an mbuf > in the middle just happens to have a length off by exactly the alignment > offset - in that case I can stop there, so long as the rest of the chain > is aligned, of course. This is a very real issue for me (in the form of > the IDT 77211 ATM SAR...) To be fair, this may not be a great example, > since I don't have an ethernet header to worry about. The only issue would be if the DMA on the chip could not support gathering its buffer from multiple sources. This is because you have to at least create mbuf header references (see the "zero copy" NFS code) for the data which you wish to transmit, and seperately create the headers. Unless you are doing headers + 8k payload (e.g. slightly small gigabit "jumbograms"), you aren't going to be able to reference FS buffer cache at an even page boundary (pages are 4k on x86, 8k on Alpha), so it's not like even the sendfile interface DMA's data directly from the disk into the ethernet card. Nor would you want it to do so, really, since it would disable your ability to cache the data, and that would limit you to disk speed, on average. In practice, your disk, not your bus would end up being your speed limiting factor. Even if you had an infinitely fast disk, the transmit buffer on this chip is limited to 8K, so 4K pages may be alright, but 8K pages leave no room for headers. So when you talk about "zero copy", you are generally talking minimally one copy, on data you have on hand (a copy from main memory to card memory), or two copy (a copy from disk or card to main memory to a card) for the data you have to get from somewhere else... in other words, "zero _additional_ copies". In any case, this means your argument doesn't apply to DMA gathering, when transmitting, since the data need not be in contiguous segments of physical RAM -- in other words, the ethernet header can be in a different mbuf cluster than the body of the data, so the body of the data can be alighned, from the host perspective -- and so can the ethernet headers. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B55AFD0.65F0C860>