Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Nov 2000 10:12:00 -0800 (PST)
From:      Matt Dillon <dillon@earth.backplane.com>
To:        Alfred Perlstein <bright@wintelcom.net>
Cc:        hackers@FreeBSD.ORG
Subject:   Re: bwillwrite() not right.
Message-ID:  <200011271812.eARIC0G31791@earth.backplane.com>
References:  <20001126232117.C8051@fw.wintelcom.net> <200011270853.eAR8rH229425@earth.backplane.com> <20001127095848.E8051@fw.wintelcom.net>

next in thread | previous in thread | raw e-mail | index | archive | help
:Hrm, on further thought bwillwrite would be helpful for sockets when
:the free mbufs gets low, but for now I'll just test this patch
:and probably have it committed by tomorrow night.
:
:thanks,
:-Alfred

    Well, maybe maybe not.  If you have a TCP socket with data flowing
    in both directions and you block in your write due to a low-mbuf
    situation, you effectively prevent the process from draining the
    receive side of the socket.  So I would say you definitely do not
    want any sort of bwillwrite() equivalent for writing to socket mbufs,
    at least not for TCP connections.

    What I would do instead is allow the socket write to continue (remember,
    'I/O must be able to continue to operate'), but constrict the sending
    buffer size as it drains to try to recover some memory on the write side.

    On the receive side the receiving window can only be constricted when
    allowed by the protocol.  i.e. if you advertise 8K of buffer space you
    cannot blow it back to 4K... you have to wait for 4K of data to be
    received before you can advertise 4K of buffer space available.  On the
    receiving side.  I seem to recall that there is already some code to
    handle that sort of thing, but I haven't looked at it closely.

					-Matt



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011271812.eARIC0G31791>