Jesse Brandeburg wrote:
On 6/21/06, Ben Greear <[EMAIL PROTECTED]> wrote:
Kok, Auke wrote:
> CRC stripping is breaking SMBUS-connected BMC's. We disable this
> feature to make it work. This fixes related bugs regarding SOL.
Shouldn't you also have to subtract 4 bytes when setting the skb len
in the receive logic? Perhaps when setting the rx-bytes counter as well?
we thought about this, but most drivers don't strip the CRC, and we
couldn't find any tests including bridging that cared if the CRC was
there in the indicated packet.
If you can find me a failing case I'll fix it. It was much simpler to
leave it out, especially when we add back in the multiple descriptor
receive code in the future (think about the case when subtracting the
CRC makes the last descriptor disappear)
Once again, let me know if you have info I don't :-)
It should only be a problem if skb->len includes the extra 4 bytes for
the crc. Then, if I transmit that skb to another interface, I am afraid
that the crc will be seen as data in the packet. In the 2.6.13 days,
the e1000 did not strip the CRC, but it subtracted 4 before it did the
skb_put. So, the crc was correctly stripped/ignored. The e100
functioned similarly I believe.
If you skb_put the extra 4 bytes, I believe this will break my
(proprietary) app because on transmit it will append the extra 4 crc
bytes, but that isn't your problem..and I can work around it. If the
receiving NIC can handle pkts 4 bytes bigger than normal, it will
probably still receive the packet w/out problem, but in truth, the frame
will not be exactly correct.
When you did your bridging tests, did you sniff the packets on the far
side of the bridge to see if they were the right size?
Thanks,
Ben
Thanks for the review,
Jesse
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
