fix(iroh-net): Also check the last packet in MagicSock::poll_recv

[matheus23]

Description

These are the quinn docs for RecvMeta::stride:

/// The size of a single datagram in the associated buffer
///
/// When GRO (Generic Receive Offload) is used this indicates the size of a single
/// datagram inside the buffer. If the buffer is larger, that is if [`len`] is greater
/// then this value, then the individual datagrams contained have their boundaries at
/// `stride` increments from the start. The last datagram could be smaller than
/// `stride`.
///
/// [`len`]: RecvMeta::len

So, meta.len isn't necessarily evenly divided by meta.stride, and the last packet could be smaller than the stride.

The previous code assumed so, however. I think that's a bug. Not bad enough that this caused issues, but still bad.

Breaking Changes

None

Notes & open questions

What are the exact effects of this code having been incorrect before?

I guess one piece is that the metrics for computing the # received bytes was way off.

Should we test this somehow specifically?

Change checklist

• Self-review.
• [ ] Documentation updates following the style guide, if relevant.
• [ ] Tests if relevant.
• All breaking changes documented.

[github-actions]

Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh/pr/2650/docs/iroh/

Last updated: 2024-08-26T14:31:59Z

[flub]

Let's at least add trace logging for this. maybe we should also do the metrics directly as well. I think two metrics:

• number of GRO datagrams
• number of datagrams a GRO datagram expands into

[flub]

I'd prefer to call this "datagram", so recv_gro_datagrams.

I think this is in line with the RFC9000 terminology:

• A datagram is a single UDP, err... datagram sent. This is pretty universal UDP networking terminology.
• A packet is something that can be sent in a single datagram. Though some packets can be coalesced together into a datagram where needed (mostly the handshake).
• A frame is what is put in packets, again you can have multiple frames per packet.

[flub]

yes, our log messages confuse this terminology too. one day that will be cleaned up too :)

[matheus23]

Yeah I went back and forth on that quite a bit.

Generally love any advice to consistent naming here. I've spent some time googling around, but people are arguing many ways.

You say "some packets can be coalesced together into a datagram", what kinds of packets are we talking about here?
This is super confusing to my ears because when I hear "packet" I think "IP packet". But I guess it can also mean "QUIC Packet"?

[flub]

Please rename the metrics, otherwise looks good.