Date: Mon, 28 Oct 2002 23:07:37 -0800 (PST) From: Kelly Yancey <kelly@nttmcl.com> To: freebsd-arch@freebsd.org Subject: RFC: Exporting number of bytes of protocol data to userland Message-ID: <20021028230434.U91753-200000@alicia.nttmcl.com>
next in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
--0-34758017-1035866312=:87083
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <20021028230434.O91753@alicia.nttmcl.com>
The attached patch is rather short so the impatient can probably skip
right to the source.
The background is that there are at least 3 interfaces which report the
"number of bytes in the socket buffer" to userland:
ioctl(s, FIONREAD, &len)
stat(2) via the st_size member of struct stat
kqueue(2) via data member of struct kevents returned for
EVFILT_READ filters.
The problem is that the number of bytes in a receive socket buffer is a
trivial piece of information at best. Since there is no way for an
application to determine how much of that data is non-protocol data (i.e.
OOB, control, etc), it cannot use the number of anything: all of the
kernel interfaces for reading from a socket buffer take the number of
bytes of *protocol data* as their length parameter (actually, this is a
slight exageration: TCP does well since OOB data is handled differently
than OSI protocols).
PR 30634 touches on this issue; UDP sockets are particularly visible
examples since they always include 16 bytes of address information in
addition to the datagram received.
The attached patch adds an additional member to the sockbuf structure to
track the amount of non-protocol data in the buffer so that interfaces can
account for that before reporting to userland. The patch also updates
stat(2) and kqueue(2) to report the number of bytes of protocol data
rather than the total number of bytes of all data in the socket buffer.
While ioctl(s, FIONREAD, &len) is also a candidate, I didn't dare touch it
because it is an old, well-documented interface. But the point is that
there needs to be at least one interface which reports a value to userland
that it can actually use.
As alluded to above, TCP sockets should be unaffected because they have
no non-protocol data in the socket buffer so the majority of socket-using
applications won't notice the change at all. However, UDP sockets and
non-IP sockets will benefit from knowing how much readable data is
available.
A version of this patch has been floating around -net for over a week
now with no comments but since it slightly changes API semantics I thought
it best to give it another round of review on -arch before committing.
Thanks,
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} -- kelly@nttmcl.com
--0-34758017-1035866312=:87083
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="sb_ctl.diff"
Content-Transfer-Encoding: BASE64
Content-ID: <20021028203832.K87083@alicia.nttmcl.com>
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME="sb_ctl.diff"
SW5kZXg6IGxpYi9saWJjL3N5cy9rcXVldWUuMg0KPT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL2xpYi9saWJjL3N5
cy9rcXVldWUuMix2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjgNCmRpZmYg
LXUgLXAgLXUgLXIxLjI4IGtxdWV1ZS4yDQotLS0gbGliL2xpYmMvc3lzL2tx
dWV1ZS4yCTIgSnVsIDIwMDIgMjE6MDQ6MDAgLTAwMDAJMS4yOA0KKysrIGxp
Yi9saWJjL3N5cy9rcXVldWUuMgkyOSBPY3QgMjAwMiAwMzo0MjowMyAtMDAw
MA0KQEAgLTIyNiw3ICsyMjYsNyBAQCBhbmQgc3BlY2lmeWluZyB0aGUgbmV3
IGxvdyB3YXRlciBtYXJrIGluDQogLlZhIGRhdGEgLg0KIE9uIHJldHVybiwN
CiAuVmEgZGF0YQ0KLWNvbnRhaW5zIHRoZSBudW1iZXIgb2YgYnl0ZXMgaW4g
dGhlIHNvY2tldCBidWZmZXIuDQorY29udGFpbnMgdGhlIG51bWJlciBvZiBi
eXRlcyBvZiBwcm90b2NvbCBkYXRhIGF2YWlsYWJsZSB0byByZWFkLg0KIC5Q
cA0KIElmIHRoZSByZWFkIGRpcmVjdGlvbiBvZiB0aGUgc29ja2V0IGhhcyBz
aHV0ZG93biwgdGhlbiB0aGUgZmlsdGVyDQogYWxzbyBzZXRzIEVWX0VPRiBp
bg0KSW5kZXg6IHN5cy9rZXJuL3N5c19zb2NrZXQuYw0KPT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9rZXJu
L3N5c19zb2NrZXQuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNDYNCmRp
ZmYgLXUgLXAgLXUgLXIxLjQ2IHN5c19zb2NrZXQuYw0KLS0tIHN5cy9rZXJu
L3N5c19zb2NrZXQuYwk2IE9jdCAyMDAyIDE0OjM5OjE0IC0wMDAwCTEuNDYN
CisrKyBzeXMva2Vybi9zeXNfc29ja2V0LmMJMjkgT2N0IDIwMDIgMDM6NDM6
MzcgLTAwMDANCkBAIC0yMDYsNyArMjA2LDcgQEAgc29vX3N0YXQoZnAsIHVi
LCBhY3RpdmVfY3JlZCwgdGQpDQogCQl1Yi0+c3RfbW9kZSB8PSBTX0lSVVNS
IHwgU19JUkdSUCB8IFNfSVJPVEg7DQogCWlmICgoc28tPnNvX3N0YXRlICYg
U1NfQ0FOVFNFTkRNT1JFKSA9PSAwKQ0KIAkJdWItPnN0X21vZGUgfD0gU19J
V1VTUiB8IFNfSVdHUlAgfCBTX0lXT1RIOw0KLQl1Yi0+c3Rfc2l6ZSA9IHNv
LT5zb19yY3Yuc2JfY2M7DQorCXViLT5zdF9zaXplID0gc28tPnNvX3Jjdi5z
Yl9jYyAtIHNvLT5zb19yY3Yuc2JfY3RsOw0KIAl1Yi0+c3RfdWlkID0gc28t
PnNvX2NyZWQtPmNyX3VpZDsNCiAJdWItPnN0X2dpZCA9IHNvLT5zb19jcmVk
LT5jcl9naWQ7DQogCXJldHVybiAoKCpzby0+c29fcHJvdG8tPnByX3VzcnJl
cXMtPnBydV9zZW5zZSkoc28sIHViKSk7DQpJbmRleDogc3lzL2tlcm4vdWlw
Y19zb2NrZXQuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6
IC9ob21lL25jdnMvc3JjL3N5cy9rZXJuL3VpcGNfc29ja2V0LmMsdg0KcmV0
cmlldmluZyByZXZpc2lvbiAxLjEzMg0KZGlmZiAtdSAtcCAtdSAtcjEuMTMy
IHVpcGNfc29ja2V0LmMNCi0tLSBzeXMva2Vybi91aXBjX3NvY2tldC5jCTUg
T2N0IDIwMDIgMjE6MjM6NDYgLTAwMDAJMS4xMzINCisrKyBzeXMva2Vybi91
aXBjX3NvY2tldC5jCTE2IE9jdCAyMDAyIDIxOjMyOjAxIC0wMDAwDQpAQCAt
MTc4NSw2ICsxNzg1LDcgQEAgZmlsdF9zb3JlYWQoc3RydWN0IGtub3RlICpr
biwgbG9uZyBoaW50KQ0KIAlzdHJ1Y3Qgc29ja2V0ICpzbyA9IChzdHJ1Y3Qg
c29ja2V0ICopa24tPmtuX2ZwLT5mX2RhdGE7DQogDQogCWtuLT5rbl9kYXRh
ID0gc28tPnNvX3Jjdi5zYl9jYzsNCisJa24tPmtuX2RhdGEgLT0gc28tPnNv
X3Jjdi5zYl9jdGw7DQogCWlmIChzby0+c29fc3RhdGUgJiBTU19DQU5UUkNW
TU9SRSkgew0KIAkJa24tPmtuX2ZsYWdzIHw9IEVWX0VPRjsNCiAJCWtuLT5r
bl9mZmxhZ3MgPSBzby0+c29fZXJyb3I7DQpJbmRleDogc3lzL3N5cy9zb2Nr
ZXR2YXIuaA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9o
b21lL25jdnMvc3JjL3N5cy9zeXMvc29ja2V0dmFyLmgsdg0KcmV0cmlldmlu
ZyByZXZpc2lvbiAxLjk0DQpkaWZmIC11IC1wIC11IC1yMS45NCBzb2NrZXR2
YXIuaA0KLS0tIHN5cy9zeXMvc29ja2V0dmFyLmgJMTcgQXVnIDIwMDIgMDI6
MzY6MTYgLTAwMDAJMS45NA0KKysrIHN5cy9zeXMvc29ja2V0dmFyLmgJMTYg
T2N0IDIwMDIgMjE6MzQ6MTMgLTAwMDANCkBAIC0xMDUsNiArMTA1LDcgQEAg
c3RydWN0IHNvY2tldCB7DQogCQl1X2ludAlzYl9oaXdhdDsJLyogbWF4IGFj
dHVhbCBjaGFyIGNvdW50ICovDQogCQl1X2ludAlzYl9tYmNudDsJLyogY2hh
cnMgb2YgbWJ1ZnMgdXNlZCAqLw0KIAkJdV9pbnQJc2JfbWJtYXg7CS8qIG1h
eCBjaGFycyBvZiBtYnVmcyB0byB1c2UgKi8NCisJCXVfaW50CXNiX2N0bDsJ
CS8qIG5vbi1kYXRhIGNoYXJzIGluIGJ1ZmZlciAqLw0KIAkJaW50CXNiX2xv
d2F0OwkvKiBsb3cgd2F0ZXIgbWFyayAqLw0KIAkJaW50CXNiX3RpbWVvOwkv
KiB0aW1lb3V0IGZvciByZWFkL3dyaXRlICovDQogCQlzaG9ydAlzYl9mbGFn
czsJLyogZmxhZ3MsIHNlZSBiZWxvdyAqLw0KQEAgLTIyNyw2ICsyMjgsOCBA
QCBzdHJ1Y3QgeHNvY2tldCB7DQogLyogYWRqdXN0IGNvdW50ZXJzIGluIHNi
IHJlZmxlY3RpbmcgYWxsb2NhdGlvbiBvZiBtICovDQogI2RlZmluZQlzYmFs
bG9jKHNiLCBtKSB7IFwNCiAJKHNiKS0+c2JfY2MgKz0gKG0pLT5tX2xlbjsg
XA0KKwlpZiAoKG0pLT5tX3R5cGUgIT0gTVRfREFUQSkgXA0KKwkJKHNiKS0+
c2JfY3RsICs9IChtKS0+bV9sZW47IFwNCiAJKHNiKS0+c2JfbWJjbnQgKz0g
TVNJWkU7IFwNCiAJaWYgKChtKS0+bV9mbGFncyAmIE1fRVhUKSBcDQogCQko
c2IpLT5zYl9tYmNudCArPSAobSktPm1fZXh0LmV4dF9zaXplOyBcDQpAQCAt
MjM1LDYgKzIzOCw4IEBAIHN0cnVjdCB4c29ja2V0IHsNCiAvKiBhZGp1c3Qg
Y291bnRlcnMgaW4gc2IgcmVmbGVjdGluZyBmcmVlaW5nIG9mIG0gKi8NCiAj
ZGVmaW5lCXNiZnJlZShzYiwgbSkgeyBcDQogCShzYiktPnNiX2NjIC09ICht
KS0+bV9sZW47IFwNCisJaWYgKChtKS0+bV90eXBlICE9IE1UX0RBVEEpIFwN
CisJCShzYiktPnNiX2N0bCAtPSAobSktPm1fbGVuOyBcDQogCShzYiktPnNi
X21iY250IC09IE1TSVpFOyBcDQogCWlmICgobSktPm1fZmxhZ3MgJiBNX0VY
VCkgXA0KIAkJKHNiKS0+c2JfbWJjbnQgLT0gKG0pLT5tX2V4dC5leHRfc2l6
ZTsgXA0K
--0-34758017-1035866312=:87083--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021028230434.U91753-200000>