This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Odd Length mbufs in Chain

Hi Andrew,

I'd like to understand better why this is a problem - Should the Ethernet driver be allowing chains with odd lengths in the middle, or should the upper layers be formatting the chains correctly ? I don't suppose we want the stack to be copying entire chains into a new buffer to avoid this. (I'm using the FreeBSD stack by the way).

I would take a closer look at the true FreeBSD OS stack and see what it does in its Ethernet layer. See if it can accept odd mbuf lengths, or if it has any special cases code to handle this.

Thanks for your response. I haven't yet studied the upper layers of the FreeBSD stack for sends, but I did find a few Ethernet drivers that handle this case.

The FreeBSD driver if_ed.c has the following send code (for cards requiring word transfers), which handles odd-length mbufs in a chain:

while (m) {
	len = m->m_len;
	if (len) {
		data = mtod(m, caddr_t);
		/* finish the last word */
		if (wantbyte) {
			savebyte[1] = *data;
			ed_asic_outw(sc, ED_NOVELL_DATA, 						     *(u_short *)savebyte);
			wantbyte = 0;
		/* output contiguous words */
		if (len > 1) {
			ed_asic_outsw(sc, ED_NOVELL_DATA,
				data, len >> 1);
			data += len & ~1;
			len &= 1;
		/* save last byte, if necessary */
		if (len == 1) {
			savebyte[0] = *data;
			wantbyte = 1;
	m = m->m_next;

Also the eCos NS dp83902a driver does a similar thing if CYGHWR_NS_DP83902A_PLF_16BIT_DATA is defined.

It looks to me like the drivers cannot expect to be passed even-length mbufs mid-chain, so I'll need to mod the 91c111 driver to handle this case.


Before posting, please read the FAQ:
and search the list archive:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]