[libfabric-users] udp packets and jumbo frames

[Xiong, Jianxin]

The hard coded value 1472 I believe is based on MTU size of 1500. For jumbo frames, the value can be increased accordingly. E.g., 8972 for MTU size 9000. 

I can see three options to do this:
(1) Add a configure option for the default MTU size and initiate the attributes accordingly.
(2) Add a runtime parameter to set the MTU size and modify the attributes accordingly.
(3) Detect the MTU size of the interface being used and modify the attributes accordingly.

Either (2) and (3) alone should be sufficient. But (1) will need to be combined with (2) or (3) so that the new default can be overridden. 

You are welcome to take the task to make this enhancement, or you can open an issue here so we can have someone working on that: https://github.com/ofiwg/libfabric/issues 

-Jianxin

> -----Original Message-----
> From: Libfabric-users <libfabric-users-bounces at lists.openfabrics.org> On Behalf Of Martin Pokorny
> Sent: Tuesday, July 30, 2024 1:30 PM
> To: libfabric-users at lists.openfabrics.org
> Subject: [libfabric-users] udp packets and jumbo frames
> 
> Hello,
> 
> The application I'm working on needs to support an Ethernet network configured with jumbo frames to capture data in UDP packets, where
> each UDP packet fits into a single Ethernet jumbo frame. I'd like to use libfabric for this configuration, as I've already got an implementation
> based on libfabric for other providers. However, it seems that the value of `udpx_ep_attr.max_msg_size` defined in `prov/udp/src/udpx_attr.c`
> is hard-coded to 1472, which prevents using UDP packets with a larger payload. I don't know that this value could be determined from the
> Ethernet configuration at runtime, but as I'd be happy to have it set at compile time, would a possible approach to supporting jumbo frames of
> a known size be to increase that value appropriately? I don't think that `udpx_tx_attr.size`, `udpx_tx_attr.inject_size`, and `udpx_rx_attr.size`
> would need to change, but I'm less certain about that. In any case, I'm not trying to implement the most general, "correct" solution at this
> time, and I'm happy to patch some source files specifically for my needs. If anyone could offer any advice about what I'm trying to do, I'd
> appreciate it. TIA.
> 
> --
> Martin
> _______________________________________________
> Libfabric-users mailing list
> Libfabric-users at lists.openfabrics.org
> https://lists.openfabrics.org/mailman/listinfo/libfabric-users