It's an application responsibility to ensure that a packet sent directly to a pktio is in storage that is addressable to that interface. For packets being transmitted via the traffic manager (via odp_tm_enq()) again it is the responsibility of the application to ensure that the tm system was configured properly to be able to address the packets being enqueued to it.
Given that we don't have explicit NUMA support (yet) this is sort of a moot point. More germane to this question is adding NUMA information to the odp_pool_param_t structure used on odp_pool_create(). That's where this question becomes interesting. On Wed, Dec 16, 2015 at 1:44 PM, Maxim Uvarov <maxim.uva...@linaro.org> wrote: > On 12/16/2015 19:48, Zoltan Kiss wrote: > >> >> >> On 16/12/15 16:47, Zoltan Kiss wrote: >> >>> >>> >>> On 16/12/15 15:39, Christophe Milard wrote: >>> >>>> 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. >>>> >>> >>> Yes, for me it's quite obvious. >>> >> How you can do it opposite? odp_pktio_open() requires pool as parameter: > > odp_pktio_t odp_pktio_open(const char *dev, odp_pool_t pool, > const odp_pktio_param_t *param) > > > > >>> ? Is the fact that an >>> >>>> application will not be able to transmit packets from a pool created >>>> AFTER pktio open() was called acceptable? >>>> >>> >>> I think TX is different from that point of view. The packet should >>> obviously exist at the time of TX, but whether it came from the pool >>> supplied to odp_pktio_open() or not shouldn't really matter. >>> >> >> Or is there a particular reason you need this? I think I've missed during >> the arch call why is this important. >> >> >>> >>>> /Christophe. >>>> >>>> >>>> _______________________________________________ >>>> lng-odp mailing list >>>> lng-odp@lists.linaro.org >>>> https://lists.linaro.org/mailman/listinfo/lng-odp >>>> >>>> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lng-odp >> > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp >
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
