Hi, As part of his MTU series, Mark sent a patch to do this:
http://openvswitch.org/pipermail/dev/2016-February/066406.html On 19/02/2016 10:40, "David Evans" <davidjoshuaev...@gmail.com> wrote: >Hey Pravin & OVS wizards. > >Just found something fun. If you're updating to dpdk 2.2 the support is >better for tx handling when doing rte_mempool_create() is now ok to use >the private data size > > >You won't need the funky pointer arithmetic in __rte_pktmbuf_init() any >more as you can use the standard rte_pktmbuf_init() inside your >ovs_rte_pktmbuf_init() > > >And - the following to set the private data size to fit in your dp_packet > > >dmp->mp = rte_mempool_create(mp_name, mp_size-1, MBUF_SIZE(mtu), >MP_CACHE_SZ, >sizeof(struct dp_packet) - sizeof(struct rte_mbuf), >rte_pktmbuf_pool_init, NULL, >ovs_rte_pktmbuf_init, NULL, >socket_id, 0); > > > >This way, if you ever decide to extend to including stuff like >ipv4_fragmentation (EG if you have outgoing packets you want to match >the MTU) the dpdk frag library uses indirect buffers you can be sure that >all the pointers will line up right for > attach / detatch / free. > > >so you can make one of these > > >dmp->mp_indirect = rte_mempool_create(mp_name_indirect, mp_size-1, >sizeof(struct dp_packet), 32, >sizeof(struct dp_packet) - sizeof(struct rte_mbuf), >NULL, NULL, >rte_pktmbuf_init, NULL, >socket_id, 0); > > > >and then based on packet size do the same as the ip_fragmentation example >in dpdk. > > >Inside the rte_pktmbuf_free_seg routine is some pointer arithmetic that >needs the private data size to be set correct to find the original >direct buffer from the indirect one. > > >Hope this is useful. I don't want to submit a patch myself as my code has >all manner of other crazy application specific tricks beyond this. > > >Regards, >Dave. > > > > _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
