All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Yegor Yefremov <yegorslists@googlemail.com>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>,
	"linux-can@vger.kernel.org" <linux-can@vger.kernel.org>,
	Michal Sojka <sojkam1@fel.cvut.cz>
Subject: Re: [PATCH] candump: add option to ignore ENOBUFS
Date: Mon, 13 Jan 2014 19:15:11 +0100	[thread overview]
Message-ID: <52D42D2F.3090405@hartkopp.net> (raw)
In-Reply-To: <CAGm1_kt4Vu3wrhOivOhO3zTbT3z3Q1HjHU5XmzZmdVjUGd1_Fg@mail.gmail.com>

On 13.01.2014 11:00, Yegor Yefremov wrote:
> On Fri, Jan 10, 2014 at 11:02 PM, Oliver Hartkopp
> <socketcan@hartkopp.net> wrote:
>> Hi Yegor,
>>
>> the question about a blocking write was still not addressed :-(
> 
> Is this something to change in the generic networking stack or just
> SocketCAN core?

AFAICR it has something to do with socket buffer sizes and the poll function
which has to be implemented in CAN_RAW.

> I'm trying to add network functionality to slcanpty,c Reading from
> socket or pty doesn't make a big difference. But as soon as you try to
> send a lot of frames, you get ENOBUFS at once. I'm trying to
> understand, what is the best way to handle this situation. In cangen
> the situation is rather trivial, as one just sends. In slcanpty it
> should support simultaneous read/write, so I'll have to store unsent
> CAN frames somewhere, return to select handling and handle read stuff,
> before retrying send.

When you use a blocking write this may also slow down the original ASCII
source. You should probably think of two separate threads for rx/tx.

Regards,
Oliver


      reply	other threads:[~2014-01-13 18:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-26  9:42 [PATCH] candump: add option to ignore ENOBUFS yegorslists
2012-10-26  9:46 ` Marc Kleine-Budde
2012-10-28 20:02   ` Oliver Hartkopp
2012-10-29  8:00     ` Yegor Yefremov
2014-01-10 22:02     ` Oliver Hartkopp
2014-01-13 10:00       ` Yegor Yefremov
2014-01-13 18:15         ` Oliver Hartkopp [this message]

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=52D42D2F.3090405@hartkopp.net \
    --to=socketcan@hartkopp.net \
    --cc=linux-can@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=sojkam1@fel.cvut.cz \
    --cc=yegorslists@googlemail.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 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.