[pnfs] [PATCH] preallocate a backchannel request in xs_tcp_data_ready

[Benny Halevy]

On Nov. 29, 2007, 15:35 +0200, Trond Myklebust <trond.myklebust at fys.uio.no> wrote:
> On Thu, 2007-11-29 at 09:20 +0200, Benny Halevy wrote:
>> On Nov. 29, 2007, 7:06 +0200, Trond Myklebust <trond.myklebust at fys.uio.no> wrote:
>>> On Wed, 2007-11-28 at 18:59 -0800, Ricardo Labiaga wrote:
>>>> For my own education, what happens if xs_tcp_data_ready() can not
>>>> allocate the back channel request and does not read the data off the
>>>> socket?  Will xs_tcp_data_ready() get called again because the data is
>>>> still there?
>>> The remaining data would be handled by xs_tcp_read_discard(), and would
>>> therefore just be junked.
>> But that happens only via xs_tcp_data_recv which is not called
>> in this case.  I count on the tcp socket layer to call data_ready again
>> whenever new data is coming in, however I am still worried about stalling
>> if the receive window will fill-up after we've hit this out-of-memory
>> condition since the back pressure will prevent any new data from coming
>> in.  The solution to that could be to somehow kick start data_ready if needed
>> at xprt_free_bc_request time.
> 
> I don't understand. xs_tcp_data_recv() is the only caller of
> xs_tcp_data_read_request(). Normally the loop there will ensure that
> xs_tcp_read_discard() cleans up any data that was not read by the other
> xs_tcp_read*() routines. Why wouldn't it do so in this case?

The idea is to *not* call xs_tcp_data_recv from xs_tcp_data_ready()
if there is no req available for processing the callback.

Benny

> 
> Trond
>