Re: [PATCH net-next v42 0/8] eea: Add basic driver framework for Alibaba Elastic Ethernet Adaptor

[Xuan Zhuo <xuanzhuo@linux.alibaba.com>]

On Thu, 7 May 2026 12:30:15 +0200, Paolo Abeni <pabeni@redhat.com> wrote:
> On 5/4/26 4:44 PM, Xuan Zhuo wrote:
> > Add a driver framework for EEA that will be available in the future.
> >
> > This driver is currently quite minimal, implementing only fundamental
> > core functionalities. Key features include: I/O queue management via
> > adminq, basic PCI-layer operations, and essential RX/TX data
> > communication capabilities. It also supports the creation,
> > initialization, and management of network devices (netdev). Furthermore,
> > the ring structures for both I/O queues and adminq have been abstracted
> > into a simple, unified, and reusable library implementation,
> > facilitating future extension and maintenance.
>
> I forwarded you the comments from nipa-sashiko. There are more on
> gemini, even a good deal of them looks invalid. For future revisions, it
> would help moving this series forward to triage such comments,
> explicitly marking the invalid ones.

Allow me to summarize the situation briefly:

eea: introduce PCI framework
     Sashiko questioned if read_poll_timeout could return early by reading the
     value we just wrote. While this is a valid concern for generic PCI
     devices, it is not an issue here. In our scenario, the DPU software
     handles all IOMMU responses, ensuring that the register transition is
     atomic relative to the software service. Thus, no hardware-side race
     condition exists, and the current handshake is robust by design.

eea: introduce ring and descriptor structures
     This commit has passed regression testing multiple times and is considered
     stable. We can likely drop it from our focus list.

eea: probe the netdevice and create adminq
     Sashiko has repeatedly expressed concerns that the device might access the
     ring if eea_pci_set_aq_up fails. While the ring's DMA address is configured
     in the hardware beforehand, the device is architecturally designed to only
     begin ring processing upon a successful return from eea_pci_set_aq_up. If
     this step fails, the device remains idle and will not perform any write
     operations to the ring. Thus, there is no risk of invalid hardware access.

eea: create/destroy rx,tx queues for netdevice open and stop
     This section seems to be a persistent source of minor glitches. ^_^

eea: implement packet receive logic
     I believe this commit is ready. It hasn't triggered any meaningful issues
     for a long time. Sashiko’s concern primarily centers on error handling
     during multi-fragment processing—specifically, whether a mid-stream
     exception might cause the driver to misidentify subsequent fragments as the
     start of a new packet. However, from a driver perspective, there is little
     we can do in such scenarios; if the hardware state becomes corrupted in
     this way, it constitutes a critical hardware error that is effectively
     beyond the driver's recovery capability.

eea: implement packet transmit logic
     Sashiko requested that we clear the descriptor (desc) fields before
     dispatch. However, according to our current design, unused fields in the
     descriptor do not require explicit clearing. I believe this addition is
     unnecessary and could introduce overhead without providing actual value.
     Regarding the other points on exception handling, I maintain my previous
     stance: if the hardware enters a faulty state, the driver's ability to
     recover is inherently limited. I don't see the benefit in over-engineering
     the driver to compensate for catastrophic hardware failures.

eea: introduce ethtool support
     This commit has passed regression testing multiple times and is considered
     stable. We can likely drop it from our focus list.

eea: introduce callback for ndo_get_stats64 and register netdev
     There is a standing requirement for linear growth in the stats counters.
     However, I plan to introduce qstats (queue-specific statistics) in a future
     update, which will be a more appropriate place for such tracking. I intend
     to defer this feature until that implementation; it will not be included in
     the current version.

Thanks.













>
> Thanks,
>
> Paolo
>