[donlzx]

AFAIK, the digital interface of the physical layer (PHY) of the Ethernet stack are pretty much standardized (MII/RMII/GMII/RGMII). Most SOCs implement their own MAC layer, but are usually compatible with off-the-shelf PHY chips. The function and interface differences in proprietary MAC implementation is where the complexity of the kernel driver comes from.

Suppose that we also standardized the interface between the MAC layer and the kernel and add an FPGA inside the existing PHY chip which is opened to real-time programming, a ton of optimization can be done. For example, DDOS packets could be thrown away well before reaching the kernel space.

Previously I had done that with some low-cost FPGA kits, with less than 1K of HDL codes, it could get out only the IP packets wanted and then pass the packets directly to the application layer via the memory interface between the embedded CPU and FPGA logics.

I think a programmable network interface is well worth the money if we care enough for openness and efficiency.

[cushychicken]

You're right - MII and it's derivatives are fairly standard. I agree that the MAC -> CPU interface is the root of a lot of the complexity that the author writes about. However, that still sort of serves to illustrate my point: the software to interface with the MAC is the chunk that introduces the most variability. Standardize that and a lot of your problems are solved.

Integrating a bunch of analog/digital/vice versa fabric onto the same die is not a tenable solution to this particular issue. I'll admit the concept is mildly intriguing, but I think you'd find quickly that the silicon demands for a DAC/ADC of the quality needed to emulate any high speed waveform are a little out of reach fab wise. Too much space, not enough drive speed.