Date: Wed, 7 Feb 2001 12:22:39 -0800 (PST) From: Luigi Rizzo <rizzo@aciri.org> To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Cc: rizzo@aciri.org, wollman@khavrinen.lcs.mit.edu, bright@wintelcom.net, net@FreeBSD.ORG Subject: Re: send problem on udp socket... Message-ID: <200102072022.f17KMdR84116@iguana.aciri.org> In-Reply-To: <200102072009.PAA46020@khavrinen.lcs.mit.edu> from Garrett Wollman at "Feb 7, 2001 3: 9: 3 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> I've thought about this problem before, in the context of a TCP
> sender, where the best solution is both (a) hard and (b) significantly
> different. I had not thought about it in the case of UDP, but yes,
> that could be a significant issue, particularly since UDP packets on
> the receive queue can never be coalesced (so there's DoS potential).
>
> I think adding a (sort of) tail pointer to the socket buffer might be
> helpful. I think you want it to point to the mbuf before the last
> *record* in the socket buffer, in order for sbcompress() to do its
oh yes, this is what i am actually implementing now:
struct sockbuf {
...
struct mbuf *sb_mb_head; /* the old sb_mb */
struct mbuf *sb_mb_tail; /* last record in chain */
...
the renaming of sb_mb is just a temporary thing to easily locate
where the field is used. sb_mb_tail is only significant if sb_mb_head!=NULL
and it is such that
sb_mb_tail->m_nextpkt is always NULL.
The change seems not too invasive, the only place which is
unclear to me is uipc_usrreq.c:unp_scan().
Does the above sounds right ?
cheers
luigi
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102072022.f17KMdR84116>