From: Daniel Borkmann <daniel@iogearbox.net>
To: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Cc: netdev@vger.kernel.org, willemb@google.com
Subject: Re: af_packet / TX_RING not fully non-blocking (w/ MSG_DONTWAIT)
Date: Sat, 04 Apr 2015 00:22:14 +0200 [thread overview]
Message-ID: <551F1296.6090003@iogearbox.net> (raw)
In-Reply-To: <551D1F86.8050200@fokus.fraunhofer.de>
Hi Mathias,
On 04/02/2015 12:52 PM, Mathias Kretschmer wrote:
> Dear all,
>
> we have encountered a problem where the send(MSG_DONTWAIT) call on a TX_RING is not fully non-blocking in cases where the device's sndBuf is full (i.e. we are trying to write faster than the device can handle).
>
> This is on a WLAN radio (so it's not that hard to achieve :).
>
> Comparing the TX_RING send() handler to the regular send() handler, the difference seems to be in the sock_alloc_send_skb() call where, the regular handler passes a (flags & MSG_DONTWAIT), while the TX_RING handler always passes a 0 (block).
>
> The attached patch changes this behavior by
>
> a) also passing (flags & MSG_DONTWAIT)
> b) adjusting the return code so that -ENOBUFS is returned if no frame could be sent or to return the number of bytes sent, if frame(s) could be sent within this call.
>
> The proposed modification works fine for us and has been tested extensively with WLAN and Ethernet device.
>
> Feel free to apply this patch if you agree with this solution.
> Of course, we're also open to other solutions / proposals / ideas.
Please send a proper patch with SOB, and no white space corruption
(there are spaces instead of tabs).
+ if (skb == NULL) {
+ /* we assume the socket was initially writeable ... */
+ if (likely(len_sum > 0))
+ err = len_sum;
+ else
+ err = -ENOBUFS;
goto out_status;
What I'm a bit worried about is, if existing applications would be
able to handle -ENOBUFS? Any reason you don't let -EAGAIN from the
sock_alloc_send_skb() not pass through?
Well, man 2 sendmsg clearly describes the -EAGAIN possibility as
"the socket is marked nonblocking and the requested operation would
block". So far it was apparently not returned since here we'd just
have blocked, but strictly speaking non-blocking applications would
need to be aware and should handle -EAGAIN, that awareness might be
more likely than -ENOBUFS, imho. What do you think?
Cheers,
Daniel
next prev parent reply other threads:[~2015-04-03 22:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-02 10:52 af_packet / TX_RING not fully non-blocking (w/ MSG_DONTWAIT) Mathias Kretschmer
2015-04-03 22:22 ` Daniel Borkmann [this message]
2015-04-04 8:36 ` Mathias Kretschmer
2015-04-04 10:19 ` Oliver Hartkopp
[not found] ` <CANfWibMogTn8QSdMAci2RUeE2ROVJ92LjUDhs3nHb7NctwKiVw@mail.gmail.com>
2015-04-05 8:35 ` Mathias Kretschmer
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=551F1296.6090003@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=mathias.kretschmer@fokus.fraunhofer.de \
--cc=netdev@vger.kernel.org \
--cc=willemb@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).