[libfabric-users] udp packets and jumbo frames

Martin Pokorny mpokorny at caltech.edu
Thu Oct 24 09:35:44 PDT 2024


Hi, Jianxin;

Thanks for your reply. I'm sorry that it's taken me so long to 
respond, but I've only now found the time to think about trying to 
implement this feature myself.

"Xiong, Jianxin" <jianxin.xiong at intel.com> writes:
> 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.

These look like MTU - UDP header - IPv4 header. Minor question: 
does libfabric define any constants for the header sizes?

> 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.

I prefer either option 2 or 3. After reviewing some of the 
libfabric code, I imagine option 2 would be easier for me to 
implement, but option 3 might be better for users. In fact, option 
2 seems like it's probably relatively straightforward, and I would 
likely start with that.

For option 3, I have some questions. Determining the MTU of an 
interface, at least on linux, I believe requires an ioctl call 
with a socket file descriptor, and a device name in a ifreq 
value. I don't know where that would be best implemented: in 
udpx_domain_open(), or elsewhere? It would have to occur before 
either udpx_tx_attr of udpx_ep_attr values are created, since 
those are the types that reflect MTU values.

> 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

I'll go ahead and try an implementation of option 2, and then I 
will submit a PR if all goes well. If people prefer option 3, I'm 
happy to have that discussion in the PR, and make any desired 
changes (based on guidance I hope would be offered in that 
discussion).

Regards,
Martin

>> -----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


--
Martin


More information about the Libfabric-users mailing list