From: Ben Greear <greearb@candelatech.com>
To: "Michał Mirosław" <mirqus@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH 1/5] send-crc: Add framework to allow sending packets with customized CRC.
Date: Tue, 07 Feb 2012 16:06:00 -0800 [thread overview]
Message-ID: <4F31BC68.9000502@candelatech.com> (raw)
In-Reply-To: <CAHXqBFKbv13jL_RqbOTZp6P-TOO7iQ1211SXmMso_3LK27LkPw@mail.gmail.com>
On 02/07/2012 03:59 PM, Michał Mirosław wrote:
> W dniu 7 lutego 2012 21:43 użytkownik Ben Greear
> <greearb@candelatech.com> napisał:
>> On 02/07/2012 12:33 PM, Michał Mirosław wrote:
>>>
>>> 2012/2/7<greearb@candelatech.com>:
>>>>
>>>> From: Ben Greear<greearb@candelatech.com>
>>>>
>>>> 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@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2012-02-08 0:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-07 19:49 [PATCH 1/5] send-crc: Add framework to allow sending packets with customized CRC greearb
2012-02-07 19:49 ` [PATCH 2/5] e100: Support sending custom Ethernet CRC greearb
2012-02-07 19:49 ` [PATCH 3/5] e1000e: " greearb
2012-02-07 20:33 ` [PATCH 1/5] send-crc: Add framework to allow sending packets with customized CRC Michał Mirosław
2012-02-07 20:43 ` Ben Greear
2012-02-07 23:59 ` Michał Mirosław
2012-02-08 0:06 ` Ben Greear [this message]
2012-02-08 8:02 ` Jeff Kirsher
2012-02-08 15:55 ` Ben Greear
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F31BC68.9000502@candelatech.com \
--to=greearb@candelatech.com \
--cc=mirqus@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.