lib/ip: fix build for debug kernel

[ol-alexandra]

Make on-stack array smaller to avoid warning when building for a kernel with a lot of debug features enabled. Decrease the maximum number of IP fragments per UDP packet from 50 to 46 (and send larger datagrams without checksum).

---

Without this patch I see following issue with my debug kernel:

/home/sasha/work/level5/onload/src/lib/transport/ip/udp_send.c: In function ‘ci_udp_sendmsg_chksum.constprop’:
/home/sasha/work/level5/onload/src/lib/transport/ip/udp_send.c:201:1: error: the frame size of 1088 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
  201 | }
      | ^

I believe that nobody uses IP fragmentation nowadays, so a small regression (Onload stops from providing UDP checksum when a packet is fragmented into >46 IP fragments) is acceptable. However I have no strong opinion on this issue.

[ivatet-amd]

Pragmatically, it seems highly unlikely to come across that many fragments, and so I agree.

At the same time, can we replace this array with a sliding window to eliminate the problem of the large stack footprint so we never come back to it?

ci_udp_sendmsg_chksum(...)
{
  ...
  uint32_t csum32;
  uint64_t csum64 = ef_ipx_pseudo_hdr_checksum(af, ip, udp->len, IPPROTO_UDP);
  csum64 = ip_csum64_partial(csum64, udp, 6);   /* omit udp_check_be16 */
  ...
  while( OO_PP_NOT_NULL(p->next) ) {
    struct iovec iov;
    ...
    iov.iov_base = frag_start;
    iov.iov_len = frag_len;
    ...
    csum64 = ip_csum64_partialv_sliding(csum64, &iov, csum64);
  }
  csum32 = ip_proto_csum64_finish(csum64);
  udp->udp_check_be16 = csum32 ? csum32 : 0xffff;
}

I appreciate that functions prefixed with ip_csum64 are "private" to the checksum unit, and we might not want to expose them as-is. Instead, shall we consider an "iterator" approach similar to what the hashing libraries do, e.g. create a hash-/checksum- context, call Init(), then Update() multiple times, then Final()?

Do you find it possible and appealing?

[ol-alexandra]

Frankly, I'm not interested in IP fragmenting at all, so I am not going to implement this approach. I agree that your approach makes sense, it would be nice if you implement it.