Jakub Kicinski wrote:
> On Wed, 01 Apr 2026 20:28:46 -0400 Willem de Bruijn wrote:
> > > /* ip sub-tests - IPv4 only */
> > > + } else if (strcmp(testname, "ip_csum") == 0) {
> > > + correct_payload[0] = PAYLOAD_LEN;
> > > + correct_payload[1] = PAYLOAD_LEN;
> > > + printf("bad ip checksum doesn't coalesce: ");
> > > + check_recv_pkts(rxfd, correct_payload, 2);
> >
> > This verifies that a packet with bad csum does not coalesce to a valid
> > packet. Perhaps too paranoid but, do you also want to test the reverse
> > case?
>
> Will do, easy enough. Tho TBH I can't think of a case where this would
> matter. Bad csum pkt must bypass all GRO processing completely right?
> Because we don't want a corrupted packet to flush a valid session?
> Or you think some implementation may actually feed these packets into
> GRO to avoid waiting for a session timeout?
Interesting, I thought the opposite: this would flush an RSC context.
That's also how the OCP text is written: "An SO context closes if a
packet matches the flow, but not the other conditions."
There's a slight subtlety when sending three packets p1, p2 and p3, of
which p2 has a corrupted checksum. If three consecutive payloads, then
if p2 bypasses GRO, the other two are not consecutive so will not
coalesce either. This is the likely case for a real bit flip in
transit. Only if p2 and p3 have the same seqno would p1 and p3
coalesce if p2 bypasses GRO. That would be a weird, possibly malicious
packet, which is not much different from other TCP injection attacks.
Which have more serious consequences than coalescing efficiency.
