Steeling TCP packets...

From: Phillip Neiswanger (phil@icarus.weber.edu)
Date: Mon Dec 18 2000 - 13:00:58 EST


Hi,

I am in the process of writing a kernel driver to support some
client/server software. This software dealing mainly with packets that it
sends/receives via tcp and udp. I can't really go into the architecture
of that software, but for various performance reasons it has been decided
we should move some of our server code into the kernel. The job of this
code is mainly to route incoming client packets to the appropriate server
and to route outgoing packets to the appropriate client connection. To
improve the performance of the read-side we would like to grab packets
early from the TCP stack. I have looked over the TCP code and have found
spots in tcp_ofo_queue(), tcp_data_queue() and tcp_rcv_established() that
queue incoming packets onto a sockets buffer with a call to
__skb_queue_tail(&sk->receive_queue, skb). I would like to wrap this
function call with code that checks if it is one of our sockets and queue
it up on our buffers rather than TCPs. The sockets themselves will never
experience read() calls, but they will experience write() calls from our
code.

My question is what are the consequences of taking data at this point? It
looks like the tcp code has handled all of the acknowledging by the time
the queueing occurs, but I'm not totally sure of this. Since all data
received from the client are in the form of 512 byte packets each sk_buf
should contain a complete packet and thus out of order packets are not a
concern.

Any comments?

--

phil email: phil@icarus.weber.edu

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Dec 23 2000 - 21:00:22 EST