New Google "GVE" Driver Queued For Upcoming Linux 5.3

[phoronix]

Phoronix: New Google "GVE" Driver Queued For Upcoming Linux 5.3

Adding to the list of Linux 5.3 kernel features is a new "GVE" network driver from Google...

http://www.phoronix.com/scan.php?page=news_item&px=Google-GVE-Network-Compute-NIC

[F.Ultra]

I know that IANA way back (RFC 1700) in 1994 decided to use Big Endian as the Network Byte Order but boy is that a stupid decision to still make in 2019 when every single architecture that this code will run on will be Little Endian...

I mean, look at the code:

 for (i = 0; i < num_entries; i++)

 page_list[i] = cpu_to_be64(qpl->page_buses[i]);



 cmd.opcode = cpu_to_be32(GVE_ADMINQ_REGISTER_PAGE_LIST);

 cmd.reg_page_list = (struct gve_adminq_register_page_list) {

 .page_list_id = cpu_to_be32(qpl->id),

 .num_pages = cpu_to_be32(num_entries),

 .page_address_list_addr = cpu_to_be64(page_list_bus),

 };

Thankfully the cpu_to_be64/32 is a small fast swap operation, but still it wastes cycles for nothing gained.

[zamadatix]

I know that IANA way back (RFC 1700) in 1994 decided to use Big Endian as the Network Byte Order but boy is that a stupid decision to still make in 2019 when every single architecture that this code will run on will be Little Endian...

Ethernet was standardized by the IEEE in 1983, the byte order choice had no influence from an IETF standard released in 1994.

It's also not really a decision you "still make", you either use big endian with Ethernet or you don't use Ethernet (unless you have the power to replace every piece of software/hardware that works with Ethernet frames overnight).

[F.Ultra]

Ethernet was standardized by the IEEE in 1983, the byte order choice had no influence from an IETF standard released in 1994.

It's also not really a decision you "still make", you either use big endian with Ethernet or you don't use Ethernet (unless you have the power to replace every piece of software/hardware that works with Ethernet frames overnight).

This is not the ethernet frames, the code is for the driver registers. The reason why I brought up IANA and not Ethernet is that I still see many binary protocols developed today that use Big Endian due to Network Byte Order, perhaps I should made that clear

[speculatrix]

I'd have thought a good virtual network interface would be very simplistic and designed so as to make drivers small and efficient. Why is Google's driver so big?

[microcode]

I guess they have some reason to use this over virtio-net, but I can't see it.