> > > This second part is clearly an optimisation. If you have lots of full > > > MTU packets, 1514 bytes, they take around 24 chunks. Having the last > > > chunk only 1/2 full does not waste too much bandwidth. But if you are > > > carrying lots of small packets, say voice, 130 bytes, the wasted > > > bandwidth starts to add up. But is there a use case for 10Mbps of > > > small packets? I doubt it. > > Yes, for sure there is a possibility to get into this scenario and the protocol also > > supports that. But as proposed by you below, let's implement it as part of > > optimization later. > > > > > > So if you don't have the ability to combine two packets into one > > > chunk, i would do that later. Lets get the basics merged first, it can > > > be optimised later. > > Yes, I agree with this proposal to get the basic version merged first. > > While latency is important, so is using the available bandwidth efficiently. Here is a suggestion. We know that the tx credit available basically tells us, > how many chunks could be transmitted without overflow. Instead of stopping the netif queue based on number of skbs queued, why not stop the queue based on > number of bytes accumulated? Basically, at any given point of time, we enqueue the tx_skb_q until we are have enough bytes to cross the threshold of (tc6->tc_credit * OA_TC6_CHUNK_PAYLOAD_SIZE). > This way, during the next transmit, we could utilize the whole available credits. Bandwidth utilization between bigger frames and smaller frames would be not be vastly different. Please configure your email client to wrap emails at around 70 characters. tc_credit is 5 bits. So it is a maximum of 32. A 1514 frame takes around 24 chunks. So you only need two full size frames to consume all your possible credit. If you happen to have smaller voice packets, say 130 bytes, you need three chunks to send it. So you might want to have 10 such packets on hand in order to make use of all your credit. But if you have 10 voice packets to send in a burst, your voice quality is going to be bad, they should be 10ms to 20ms apart, not in a burst... I don't like the original idea of having lots of packets in a transmit queue. But having 1/2 dozen should not be an issue. In general, we prefer things to be simple. We can then optimise later, and use benchmarks to show the optimisations really do bring a benefit to justify the added complexity. Andrew
