Re: Question on e1000 patch, rx-copy-break related.

[Ben Greear <greearb@candelatech.com>]

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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com