Date: Fri, 10 Jan 2003 09:28:09 -0800 From: "Sam Leffler" <sam@errno.com> To: "Tim Robbins" <tjr@FreeBSD.ORG>, "Juli Mallett" <jmallett@FreeBSD.ORG> Cc: <current@FreeBSD.ORG>, <re@FreeBSD.ORG> Subject: Re: Serious issues with kqueue on sockets on CURRENT. Message-ID: <12d201c2b8cd$a52a1440$52557f42@errno.com> References: <20030110013015.A23399@FreeBSD.org> <20030110215736.A31727@dilbert.robbins.dropbear.id.au> <20030111004226.A36261@dilbert.robbins.dropbear.id.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Fri, Jan 10, 2003 at 09:57:36PM +1100, Tim Robbins wrote: > > > On Fri, Jan 10, 2003 at 01:30:16AM -0800, Juli Mallett wrote: > > > > > Lately, the data field for sockets, which holds bytes ready (in the EVFILT_ > > > READ case) to be read, is computed to be zero. This means that if you have > > > a low watermark which is >0 per the kq, THE EVENT WILL NEVER HAPPEN. Not to > > > mention that this means when the event IS triggered properly (if you can > > > call it that), it is always said to have =ZERO= bytes ready. > > [...] > > > > I can definitely reproduce this here and also fairly angry about it. > > In addition to what you mentioned, fstat() gives an incorrect st_size > > result now and it's likely that non-NOTE_LOWAT low watermarks are > > firing too early as well. > > > > Ugly test program @ http://people.freebsd.org/~tjr/kq.c > > From what I can tell, mbufs with m_type == MT_HEADER can store data > as well as those with m_type == MT_DATA. This patch corrects the > tests in sbcompress(), sbdrop(), sballoc() and sbfree() so that data > stored in MT_HEADER mbufs is not included in sb_ctl. I'd appreciate > comments from people who have a good understanding of this code. You're correct the MT_HEADER-type mbufs may have data in them. Using the mbuf type to infer the type of data held within is probably a bad idea unless the mbufs are specifically tagged as such. I'm not clear on exactly what sb_ctl is supposed to count; the comment in the cvs log is unclear: "Track the number of non-data chararacters stored in socket buffers so that the data value returned by kevent()'s EVFILT_READ filter on non-TCP sockets accurately reflects the amount of data that can be read from the sockets by applications." What are "non-data characters"? Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12d201c2b8cd$a52a1440$52557f42>