The transmit routine can be entered with multiple mbufs with mbuf->m_next
chaining the mbufs. The defrag routine is there to copy multiple mbufs
into a single buffer if the driver doesn¹t have sufficient buffers
available to transmit all the fragments.




On 2014/1/17, 1:44 AM, "Mitchell Schoenbrun" <community-noreply@qnx.com>
wrote:

>I've been having a very serious problem doing an optimization of a driver
>and it leads me to believe that I really don't understand mbuf's very
>well, ate least with respect to how io-pkt is using them.
>
>The driver works if I copy data into on transmit and out of on receipt
>using the m_copydata() and m_copyback() routines.   I've been trying to
>switch over to having the hardware move the data directly from the mbuf
>data buffer (m->m_data).
>
>This always fails.
>
>I was under the (possibly misguided impression) that io-pkt was providing
>a contiguous buffer the size of MCLBYTES each time I got an mbuf to
>transmit.  
>
>In particular, I find in the source for the e1000 driver transmit.c code
>a routine called i82544_defrag() which seems to be trying to defragment a
>packet.   If the data is delivered in a contiguous buffer, why would it
>ever need to be defragmented?    If the packet can be fragmented, then my
>problem is solved, because I will have no option other than copying it.
>
>Help please.
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post108005
>To cancel your subscription to this discussion, please e-mail
>drivers-networking-unsubscribe@community.qnx.com