Re: [PATCH 1/5] send-crc: Add framework to allow sending packets with customized CRC.

On 02/07/2012 03:59 PM, Michał Mirosław wrote:

W dniu 7 lutego 2012 21:43 użytkownik Ben Greear
[off-list ref]  napisał:

quoted

On 02/07/2012 12:33 PM, Michał Mirosław wrote:

quoted

2012/2/7[off-list ref]:

quoted

From: Ben Greear<redacted>

This is useful for testing RX handling of frames with bad
CRCs.

Requires driver support to actually put the packet on the
wire properly.

[...]

I like this idea. I think that this is not a feature to have in
dev->features to toggle, though. Driver either supports this or not,
so it's better to put it in dev->priv_flags instead. Disabling of FCS
inserting is a per-packet option in the drivers, isn't it?

For one problem with toggling: if you create a socket using it and
later turn off the feature, the socket will still send skbs with FCS
appended.

For the priv-flags, is there a way to query that from user-space to
see if the NIC supports it?

The pkt-socket xmit logic will throw away pkts if the NIC doesn't
have the feature enabled, but a few already queued might get
through with extra CRC appended.

So, I'm fine with your suggestion, as long as there is some way to
query whether the NIC supports this feature or not...

There's a way, as you implemented -EINVAL when trying to send via
unsupporting device. :-)  Would be even better if setting SO_NO_FCS
would fail at setsockopt() time.

Using -EINVAL for this purpose is lame even by my low standards :)

And, you don't necessarily know what device you are bound to
at setsockopt time, so I don't think I can add restrictions
there.

priv_flags are not exposed to userspace. It should be easy to export
them using ETHTOOL_GFEATURES as non-changeable features, if that's
useful.

I'll poke around and see what I can figure out.

Thanks,
Ben

-- 
Ben Greear [off-list ref]
Candela Technologies Inc  http://www.candelatech.com