On 9/5/24 1:20 PM, Zijian Zhang wrote:
Cases I can think of are as follows,
- When it's not a GSO skb, tcp_skb_seglen will simply return skb->len,
it might make `tp->mss_cache - tcp_skb_seglen(skb)` a large number.
- When we are in tcp_mtu_probe, tp->mss_cache will be smaller than
tcp_skb_seglen(skb), which makes the equation again a large number.
In tcp_mtu_probe, mss_cache is (smaller) than the tcp_skb_seglen(skb)?
```
tcp_init_tso_segs(nskb, nskb->len);
if (!tcp_transmit_skb(sk, nskb, 1, GFP_ATOMIC)) ...
```
In the tcp_transmit_skb inside tcp_mtu_probe, it tries to send an skb
with larger mss, so I assume mss_cache will be smaller than
tcp_skb_seglen(skb). Sorry for the confusion here.
hmm... "mss_cache - tcp_skb_seglen(skb)" and mss_cache could be smaller...
This is another signal that this approach does not sound right. I am not
positive tbh. Given that I have already suggested more than one other ways. If
you really eager to pursue this route to improve bpf_reserve_hdr_opt(), the
tests coverage has to be convincing enough to cover corner cases like this for
example.
pw-bot: cr
