Hi David, > You could just comment that that count++ is in case the linear part > has the extra fragment.
> Put that in the commit message. Will do both in v3. > c) Adjust the DIV_ROUND_UP() for the linear part. > I think: > DIV_ROUND_UP(len + adapter->tx_fifo_limit - 372, adapter->tx_fifo_limit) > is right. For TSO packets, yes, although it would need min(tx_hdr_buf_max, tx_fifo_limit) for parts with a larger max_read_request, and without an mss check it also changes the count for every other packet. I'd keep that, the unconditional context count++ and pre-calculating the post-transmit limit for a separate cleanup. > Although I wonder if you really want to be doing all those divides? > I'm guessing that tx_fifo_limit is usually 24k (and the actual buffer larger). > So the result is almost always 1. Not on the I219. PBA reads 0x0006001a there, 26 KB for Rx and only 6 KB for Tx, so tx_fifo_limit is 6048; in the ring dumps from my test host, 127,676 data descriptors were exactly that size: https://github.com/andrebrait/e1000e-i219-tso-hang/blob/5f247ecec758/evidence/related/tx-allocation.txt Page fragments of up to 32 KB take several descriptors each, so the divides do matter there. > (Indeed, does TSO and checksum insertion work if the packets are longer > than the real buffer?) TSO does: in a 3-minute window on the patched driver, 39,725 of 40,223 TSO packets were larger than 6048 bytes, up to 65,226 (45 segments), and the receiver verified every byte: https://github.com/andrebrait/e1000e-i219-tso-hang/blob/5f247ecec758/evidence/related/tso-larger-than-tx-buffer.txt Only each descriptor has to fit, hence the cap. Plain checksum insertion only sees frames up to the MTU; for jumbo frames e1000e_reset() moves space from Rx to Tx to fit two full frames. I haven't tested jumbo frames. Nothing in the patch depends on the MTU (it only shortens the first descriptor of a TSO packet), so I don't expect it to change their behaviour, but I can run the same tests with jumbo frames if you'd like. Andre
