RE: Asynchronous sock_sendmbuf
RE: Asynchronous sock_sendmbuf
- Subject: RE: Asynchronous sock_sendmbuf
- From: "Eddy Quicksall" <email@hidden>
- Date: Thu, 22 May 2008 17:08:24 -0400
You must have misunderstood something. I don't poll. I use the upcall. And I
don't get EWOULDBLOCK.
Wouldn't the mbufs be freed as the tcp/ack's arrive? It seems that ((struct
tcpcb*)(sotoinpcb_hdr(so)->inph_ppcb))->snd_una) would tell when space is
becoming available. Then if another so_send is done then data would be moved
to the available mbuf's and everything would proceed nicely. So you don't
need a guarantee of space, just a hint that there may be more space.
Everyone knows that there is no guarantee that the application actually got
the data just because you get an ack. But that is what upper level recovery
is for.
Eddy
-----Original Message-----
From: Terry Lambert [mailto:email@hidden]
Sent: Thursday, May 22, 2008 3:51 PM
To: Eddy Quicksall
Cc: Igor Mikushkin; email@hidden
Subject: Re: Asynchronous sock_sendmbuf
Thread switches not involving a protection domain or address space
crossing are essentially free.
Marshalling send data to a blocking send thread would require
synchronization, which could result in stall barriers, but this
overhead has to be traded against that of retrying the same
outstanding internal send request multiple times and getting
EWOULDBLOCK, plus the polling requirement given a lack up a send
specific upcall. So the efficiency claim may not be valid.
In general, no send specific upcall that existed could guarantee send
buffer space in any case, given the possibility that your mbufs are
ehausted and/or multiple writers competing for send space.
Also, as Mike pointed out, data not in your send buffer any more does
not imply data received at the other end. Even an ack-based upcall
based on data acknowledged, assuming a direct link and no intermediate
bridging or stateful firewall, would only mean that the data had
gotten to the targets receive buffer, not that the target application
had receive it. The only way to guarantee this would be an
application layer acknowledgement, probably in-band.
-- Terry
On May 22, 2008, at 10:51 AM, Eddy Quicksall <email@hidden
> wrote:
> I'm using non-blocking / upcall because (1) it is more efficient than
> switching threads and (2) I only need one thread for all connections
> (and 3,
> it is an embedded application and not much memory is available for
> lots of
> threads).
>
> Eddy
>
> -----Original Message-----
> From: darwin-kernel-bounces+quicksall_temp=email@hidden
> [mailto:darwin-kernel-bounces+quicksall_temp=email@hidden
> ]
> On Behalf Of Terry Lambert
> Sent: Wednesday, May 21, 2008 7:31 PM
> To: Igor Mikushkin
> Cc: email@hidden
> Subject: Re: Asynchronous sock_sendmbuf
>
> On May 21, 2008, at 3:30 AM, Igor Mikushkin wrote:
>> Network Kernel Extensions Programming Guide says here:
>> If your code is in a performance-critical part of the kernel (as
>> opposed to a call from user space), you should generally perform
>> socket I/O asynchronously.
>
> This is to prevent you from blocking on a write, and having everything
> pile up behind you waiting for you. For example, if your KEXT is a
> block device driver that does network based logging, then blocking on
> logging is going to prevent anything talking to your block device
> driver from talking to the media while you are busy waiting for the
> logging to occur.
>
> It's perfectly reasonable to marshall the I/O off to another thread,
> and have it make a blocking call on your behalf, so long as you don't
> depend on the call having been made for subsequent operations to be
> successful
>
> -
>
> Maybe we can step back a second...
>
> What are you trying to accomplish here that you think getting an
> upcall would accomplish for you?
>
> -- Terry
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Darwin-kernel mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> uth.net
>
> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden