On Nov 13, 2006, at 10:22 AM, Izumi Tsutsui wrote:

> thorpej@shagadelic.org wrote:
>
>>> (though rtl8169.c should have some flag which indicates RTL8168  
>>> quirk,
>>>  which can't xfer RX packets into unaligned buffers)
>>
>> So, we'd have a RE_ETHER_ALIGN(sc) macro that wraps it?  Sounds good.
>
> To handle RTL8168 on !__NO_STRICT_ALIGNMENT hosts case,
> we have to copy RX DMA buffer (which is word align)
> to a new mbuf with ETHER_ALIGN padding, as other drivers
> (vr(4), tlp(4), vge(4) etc.) does, IIUC.
>
> I wonder which is more efficient way to copy received buffer,
> allocating a new mbuf, or moving data toward 2 bytes in the
> same mbuf, which is used in vge(4).

Maybe allocate a new mbuf, copy a "typical" amount of data (i.e.  
Ethernet header + IPv4 header + TCP/IP header + typical TCP options)  
into new mbuf (offset 2 bytes from beginning of mbuf), adjust the  
received packet past the data copied into the new mbuf, prepend the  
new mbuf onto the received packet.

Allocating mbufs is fairly cheap because of pool_cache.  A lot cheaper  
than copying an entire packet (especially an overlapping copy like vge  
uses!)

-- thorpej