[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [virtio-comment] RE: [PATCH v19] virtio-net: support inner header hash
> From: Michael S. Tsirkin <mst@redhat.com> > Sent: Wednesday, June 28, 2023 1:16 PM > > 1. Because than device is 100% sure that it does not fulfill MMIO > > needs 2. Single interface to access extended config space, which is what you > asked for. > > 3. Single driver code because there is single way to get it. > > > > Right. But I think there's a better way. > Just say that any feature in MMIO MUST be also in DMA. > So any modern driver will have no reason at all to use MMIO - DMA is a > superset. > How does that relax the need of MMIO for the device? > If we say that drivers should use DMA, they will. If we additionally explain that > some features might not be in MMIO no sane driver will use MMIO if it does not > have to. > Or if it does then it has violated the spec and will get less features? > So than why to have it in MMIO anyway? Why not say driver must use dma? > > This demands two ways of access and that conflicts with your point of desire > to do single way. > > I proposed single way, extended config space via DMA interface, that is really > as simple as that. > > > My desire is to have a single way that works for everything. > We have legacy so we will have legacy ways too, these might not work for > everything. Here is what can work well, A device tells the offset of the extended config space to the driver. Any field starting from that offset must be accessed via a DMA interface. This way, driver must support DMA and all new features come from there. If device chose to use MMIO, say sw, it can still do it using MMIO.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]