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 <greearb@xxxxxxxxxxxxxxx> napisał:On 02/07/2012 12:33 PM, Michał Mirosław wrote:2012/2/7<greearb@xxxxxxxxxxxxxxx>:From: Ben Greear<greearb@xxxxxxxxxxxxxxx> 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 <greearb@xxxxxxxxxxxxxxx> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html