Messages in this thread | | | Subject | Re: sk_buff chaining | From | Jes Sorensen <> | Date | 20 Nov 1999 16:37:06 +0100 |
| |
>>>>> "John" == John Justice <justice@quantumres.com> writes:
John> My question is somewhat network oriented. It appears that LINUX John> socket buffers sk_buff) contain the whole contiguous packet and John> there is no mechanism to represent a packet as a scatter / John> gather list. For ethernet (MTU=1500) this is not a problem, John> however, Fibre Channel devices specify an MTU of 65280 John> bytes. The major problem is posting buffers to the adapter for John> recieving packets. Under SOLARIS, for example, I can post 4k John> buffers to the adapter. The driver can then chain these 4k John> buffers together if the packet recieved is > 4K. With LINUX, John> however, I have to post 64K buffers to the adapter since there John> is no mechanism to chain sk_buffs together. Depending on the John> TCP/UDP application being run (like telnet / rlogin), this will John> be a huge waste of memory. Is there a way to somehow chain John> sk_buffs in present / future versions of LINUX?
What you are asking for is mbufs, fortunately we don't support those. Currently there is no support in the kernel for scatter/gather type lists in the skbuffs, however the long time solution is to make the skbuffs kiobuf aware, which will allow you to post pages to the device and chain them together in the receive handler.
However the telnet/rlogin (eeek, nobody should use those when ssh exists) problem is easy to solve, just use the copy-break trick used by almost every network driver for a DMA capable device. In the rx handler you simply check if the incoming packet is smaller than say 300 bytes, if it is you creat a new skb and copy the data there and hand the old one back to the device.
I had the same problem when I did the Road Runner HIPPI driver which has the same MTU problem (65280 bytes).
Jes
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |