Date: Mon, 11 Aug 1997 21:54:20 -0500 From: Chris Csanady <ccsanady@friley01.res.iastate.edu> To: Curt Sampson <cjs@portal.ca> Cc: freebsd-hackers@freebsd.org Subject: Re: DISCUSS: interface for raw network driver.. Message-ID: <199708120254.VAA04339@friley01.res.iastate.edu> In-Reply-To: Your message of "Mon, 11 Aug 1997 09:04:13 PDT." <Pine.NEB.3.96.970811085147.8496D-100000@cynic.portal.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
> >I should preface this post with the comment that I'm not any huge >expert on high performance networking; I just read up on it when >I can. > >On Mon, 11 Aug 1997, Chris Csanady wrote: > >> o An ack function in the pseudo-device to call when the send is complete. >> ... >> o An input function in the pseudo-device to be called upon reception of >> a packet. > >If you're interested in performance, you want to batch these as >much as possible to avoid interrupts. You should be able to chain >sends, at the very least. Possibly even better, if you're really >slamming stuff through the interface, would be for the application >to have a whole series of buffers that it fills and adds to the >chain, and when it runs out (or comes near to running out), a >function it can call to get a list of the buffers that have been >sent and are now free. Of course, there's some work to do here >regarding the best way to feed errors back to the application. This is not a bad idea, and would be fairly simple to implement. >For receive packets, you have to figure out what sort of trade-off >you want to make between latency and speed, and this is really an >application decision. If possible, deal with the reception of >several packets with just one interrupt. What I currently have in my driver allows for multiple receive packets to be serviced at interrupt time. However, if you only interrupt so often, you will have to implement a timeout mechanism as well. >But in the end, your whole strategy is not the right way to go as >far as really good performance, except in the (in these days unusual) >case where the application uses its own private protocol. If you But we do want to use our own protocol. The end goal is to use this as a bottom end for MPI or other parallel applications/etc.. >want to see how to deal with TCP/IP over Gigabit Ethernet, I really >strongly recommend reading ``DART: Fast Application-Level Networking >via Data-Copy Avoidance'' by Robert J. Walsh in The July/August >1997 (v 11 n 4) issue of _IEEE Network_. Do you have a url? Although I definately don't have the time to reimplement a large chunck of the TCP/IP stack, I am definately interested. I was hoping to work on implementing Van's pbuf architecture this summer, but I haven't had the time. Overall, I think that in the end, a real protocol is the way to go.. although there are just none that are efficient enough to take advantage of todays high speed networks. Chris > >cjs > >Curt Sampson cjs@portal.ca Info at http://www.portal.ca/ >Internet Portal Services, Inc. Through infinite myst, software reverberates >Vancouver, BC (604) 257-9400 In code possess'd of invisible folly. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708120254.VAA04339>