On Fri, Nov 15, 2024 at 02:52:57PM +0100, Morten Brørup wrote: > > From: Robin Jarry [mailto:rja...@redhat.com] > > Sent: Friday, 15 November 2024 14.02 > > > > Morten Brørup, Nov 14, 2024 at 15:35: <snip> > > > > On that same topic, I wonder if it would make sense to change the API > > parameters to use an opaque rte_ipv4_addr_t type instead of a native > > uint32_t to avoid any confusion. > > It could be considered an IPv4 address type (like the IPv6 address type) > (which should be in network endian), which it is not, so I don't like this > idea.
Can you clarify your objection to this idea? For me, the idea of having IPv4 addresses as a 4-byte array seems to offer a lot of advantages over treating it as a single 32-bit value. We don't need to worry about packing or alignment of the values, and everything would always be treated in network-byte order. The main downside I see is compatibility - we'd need a whole new set of definitions and functions in libs to make the change. /Bruce
