isn't it defeating the purpose of the iommu to DMA map all possible mem that could be used in a pool?... And as long as the memory is not mapped in the user virtual space, vfio won't let me do that...
On 17 December 2015 at 14:24, Alexandru Badicioiu < [email protected]> wrote: > Why the driver must map pools one by one? Is this a (legacy) kernel driver? > The driver can map one or more DMA-ble memory regions at initialization > time and this memory region should be used for all PACKET type pools. > > Alex > > On 17 December 2015 at 15:15, Christophe Milard < > [email protected]> wrote: > >> The question is related to the DMA mapping: >> The driver needs to perform the DMA mapping, and we don't want to set up >> a new DMA mapping at TX time for each individual packet: We want to set-up >> the DMA at pktio_open() time, I guess, so that the NIC DMA can fetch any TX >> packet to be transmitted in the future. >> If we agree that the DMA mapping has to be done at some init time rather >> than at each packet transmit time (which seems abvious), then, I need to >> know, at that init time, what memory has to be DMA mapped to enable >> fetching any possible buffer in the future (i.e. at TX time). >> If I DMA mapp all paket pool regions known at pktio_open() time, then any >> packet pool created later will not be part of the mapping, unless a hook is >> added so that any pool creattion calls a function in the driver that >> performs the additionnal mapping. >> >> >> On 17 December 2015 at 10:09, Savolainen, Petri (Nokia - FI/Espoo) < >> [email protected]> wrote: >> >>> It’s better to allow packet output from any packet type pool, no matter >>> when the pool was created. Implementation controls packet pool memory >>> mapping and can e.g. arrange all packet pool memory to be contiguous (in >>> global init time). Each packet pool create could update IOMMU or if entries >>> are scarce one or few entries could map the entire packet pool memory area. >>> >>> >>> >>> Before – after API call relations would get cryptic and hard to maintain >>> / debug in a complex application (multiple pktios and pools, created on >>> different parts of the application). >>> >>> >>> >>> -Petri >>> >>> >>> >>> >>> >>> >>> >>> *From:* EXT Christophe Milard [mailto:[email protected]] >>> *Sent:* Wednesday, December 16, 2015 5:39 PM >>> *To:* Petri Savolainen; Ola Liljedahl >>> *Cc:* Eric Davis; LNG ODP Mailman List >>> *Subject:* Pool DMA mapping >>> >>> >>> >>> Hi, >>> >>> >>> >>> Following the discussion at the ARCH call, today, would it be reasonable >>> to require that all packet pools that can be used by a NIC have to be >>> created before the related nic pktio is opened? -This is implicitly >>> required in RX, as the pool handle from which buffer should be allocated in >>> RX is a parameter to the pktio_open() function. Is the fact that an >>> application will not be able to transmit packets from a pool created AFTER >>> pktio open() was called acceptable? >>> >>> >>> >>> /Christophe. >>> >> >> >> _______________________________________________ >> lng-odp mailing list >> [email protected] >> https://lists.linaro.org/mailman/listinfo/lng-odp >> >> >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
