Jesse Brandeburg wrote:
My personal preference is to set a flag in the skb struct indicating
whether
or not the crc is appended (and skb_put). Then, bridging code can
ignore it if needed,
and sniffers and such can get the CRC in user-land. To remain
backwards compat,
at least the skb-put of the crc logic should default to OFF so that we
don't
break any existing user-land bridging logic. I have the ethtool API
logic written to
twiddle this save-crc behaviour if someone decides this is worthy of
the kernel.
that seems like an excellent idea, however, finding room in the skb
struct is fun.
This field has 2 bits free. We only need one bit for this feature.
__u8 pkt_type:3,
fclone:2,
ipvs_property:1;
> Well, its a changing picture. I had planned to eventually enable the
> hardware to strip the CRC if we aren't connected to some kind of
> offboard management. We'll get there in steps.
So, as of 2.6.16.13, is the hardware stripping (SERC) enabled? Could
you also let me know where this bit is defined in case I want to twiddle
it myself (a quick grep for SERC in 2.6.16.13 yields nothing.)
Yes, SECRC is enabled in 2.6.16, for both packet split and legacy
receive paths. It will probably stay enabled for 2.6.17 too unless
the BMC communication bug is rated important enough for the change to
be made. Unfortunately right now due to SECRC bit being set BMC
communication over SMBUS is likely broken.
Ok, thanks for the info.
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
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
