This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
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);
data++;
len--;
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.
Cheers,
Kelvin.
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss