On Mon, 16 Nov 1998, Alan Cox wrote: > > Can I do the following? When hard_start_xmit gets called > > and I want to delay the transmission, can I just return 0, > > but not free the skb yet? I then put it on a list, > > Yes > > > which I maintain on my own. I then send it at a later time > > and free the skb. Is there anything wrong with this approach? > > Nothing. The buffer handed to you is locked. It is going nowhere until > you unlock it (dev_kfree_skb does an unlock..) > > Equally you don't want to queue many frames or you'll get poorer tcp > performance or queue them forever. Say, what's a good formula for determining how many packets to queue? I don't necessarily mean internal queues in the driver, but the overall queue length, including the queue maintained by the device subsystem over top of your device. I know that ethernets have a queue size of a hundred, and SLIP and PPP use a queue size of about ten. It would seem that the queue length should be the amount of data that your packet can drain within some reasonable period, like half a second. But you don't want to be so small that your TCP can't send a decently-sized window blast. I can't get my Mobitex driver to perform well with TCP at all. I've tried fiddling with the queue lengths and setting large irtt values on the routes to no avail. It seems to be behaving as though it were permanently stuck in slow start, sending individual packets only when an ack is received. You would think that it could pick up the pace if told that the round-trip time is large. The round-trip times are large, like 4-6 seconds, and gets worse when you ``load up'' the network. And the transfer rate is poor as well, about 4800 baud at best. - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to [EMAIL PROTECTED]
