As far as I am aware it was original when Linux first did it (and we broke cisco pix, some boot proms, some sco in the process). Credit goes to Arnt Gulbrandsen probably better known nowdays for his
alan, good to know. it's a nice piece of engineering. it's useful to note that linux has such a long and rich history of breaking de-facto standards in order to make things work better. t. -- todd un
Quoting Todd Underwood <todd@xxxxxxxxxxxxx>: Some of that may be a byproduct of the "all the worlds' a webserver" mindset - we are primarily focussed on the server side (aka money side ;)), and there
I disagree, at least for bulk receivers. We have no way currently to get rid of the data copy. We desperately need sys_receivefile() and appropriate ops all the way into the networking, then the nece
dave, all, not sure i understand what you're proposing, but while we're at it, why not also make the api for apps to allocate a buffer in userland that (for nics that support it) the nic can dma dire
Quoting todd-lkml@xxxxxxxxxxxxx: I believe thats exactly what David was referring to - reverse direction sendfile() so to speak.. However, I dont think what youre saving are interrupts as much as the
Cards in the future at 10gbit and faster are going to provide facilities by which: 1) You register a IPV4 src_addr/dst_addr TCP src_port/dst_port cookie with the hardware when TCP connections are ope
10 gige becomes more of an interesting beast. Not sure if we would see servers with 10gige real soon now. Your proposal does make sense although compute power would still be a player. I think the key
Your proposal does make sense although compute power would still be a player. I think the key would be parallelization; Oh I forgot to mention that some of these cards also compute a cookie for you o
david, comments/questions below... intriguing architecture. are there any standards in progress to support this. bascially, people doing high performance computing have been customizing non-commodity
are there any standards in progress to support this. Your question makes no sense, it is a hardware optimization of an existing standard. The chip merely is told what flows exist and it concatenates
folx, perhaps i was insufficiently clear. hardware optimizations can be standardized. in fact, when they are, it is substantially easier to implement to them. my assumption (perhaps incorrect) is tha
The system calls would go into the VFS, sys_receivefile is not networking specific in any way shape or form. And to answer your question, if I had the time I'd work on it yes. Right now the answer to
There is an assumption that one is a linear stream of output (in this case a socket) and the other one is a page cache based file. It would be nice to extend sys_sendfile to work properly in both way
That's an implementation detail and it's not clear we should be exposing it to the user. It's not entirely insane to contemplate socket->socket or too? File descriptors are file descriptors. Yeah --
Er, surely the same goes for sys_sendfile? Why have a new system call rather than just swapping the 'in' and 'out' fds? There is an assumption that one is a linear stream of output (in this case a s
David S. Miller wrote: From: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx> Date: Mon, 16 Sep 2002 19:08:15 -0400 I was rather disappointed when file->file sendfile was [purposefully?] broken in 2.5.x... Wha
I dunno when it happened, but 2.5.x now returns EINVAL for all file->file cases. In 2.4.x, if sendpage is NULL, file_send_actor in mm/filemap.c faked a call to fops->write(). In 2.5.x, if sendpage is