Julian Elischer wrote:
On Wed, 7 Jan 2004, Jonas Bulow wrote:I guess it is struct sockbuf sn_snd in struckt socket.
Hi,
I'm trying to use netgraph and kqueue together and ran into some problems. I hope someone can enligthen me what I'm missing.
I'm not sure that anyone has ever looked at netgraph and kqueue as a pair.
I register EVFILT_READ and EVFILT_WRITE on a netgraph-socket connected to a netgraph echo-node. The EVFILT_WRITE-filter returns immediately from the kevent call saying there is 20480 bytes remaining in the write buffer (in the event data field). Then I write 20480 using NgSendData. NgSendData encounters an error: "No buffer space available".
WHat does it mean "write buffer"?
The netgraph socket will pass th edat adirectly to whatever is connected. There is no buffer. The echo node in turn passes it back to the socket node (though there maybe a lock.. not sure) so eventually the data will be put in the receive buffer, so for this case the receive buffer is the send buffer but the socket can not know this..
When I write fewer but smaller chunks of data, say ~3000 bytes, the next call to kevent returns the same amount of remaining space in the write buffer. The kqueue event data field never change from 20480 for the EVFILT_WRITE-filter.
No it is returning some default value.. I doubt it is related in any way to much of importance.
tell me, does a write of 20479 bytes work?
No, but 20473 works. The next call to kevent returns the constans 20480 again and the following NgSendData fails with the error above.
It seems to get it's value in kern/uipc_socket.c:filt_sowrite: ( -stable)
Now I understand that there are some overhead in the NgSendData. It's not just my data that are written through the socket. The addressing data adds some data when NgSendData calls sendto. Right?
nope. that is out of band data.. I don't count that.. (I don't count anything really.).
But, how do I calculate the true amount of remaining buffer space available for me when I call NgSendData?
you can't.. there is no transmit buffer.. that is a reponsibility of the node that eventually decides to queue the data (maybe never).
And, why does kevent EVFILT_WRITE always say 20480 on repeated calls to kevent on a netgraph-socket, even if I have successfully written some data between the calls to kevent?
probably some default value.
kn->kn_data = sbspace(&so->so_snd);
The netgraph-node the programming is talking to is a echo-node set up with:
#ngctl mkpeer echo dummy foo
I suggest 'following' the data in the source code...
starting in ng_socket.c
start at:
http://snapshots.jp.freebsd.org/tour/current/kernel/S/3328.html#338
for -current and:
http://snapshots.jp.freebsd.org/tour/releng4/kernel/S/2566.html#182
for -stable.
Ok, I will do that.
Isn't it kern/uipc_socket .c in sosend who is responsible for returning ENOBUFS in the first place when using the sendto that NgSendData uses?
/j
Regards, Jonas _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
