On Fri, Dec 20, 2019 at 01:14:37PM -0800, Ben Pfaff wrote: > On Fri, Dec 20, 2019 at 09:49:44AM -0800, William Tu wrote: > > On Thu, Dec 19, 2019 at 08:44:30PM -0800, Ben Pfaff wrote: > > > On Thu, Dec 19, 2019 at 04:41:25PM -0800, William Tu wrote: > > > > Currently the performance of sending packets from userspace > > > > ovs to kernel veth device is pretty bad as reported from YiYang[1]. > > > > The patch adds AF_PACKET v3, tpacket v3, as another way to > > > > tx/rx packet to linux device, hopefully showing better performance. > > > > > > > > AF_PACKET v3 should get closed to 1Mpps, as shown[2]. However, > > > > my current patch using iperf tcp shows only 1.4Gbps, maybe > > > > I'm doing something wrong. Also DPDK has similar implementation > > > > using AF_PACKET v2[3]. This is still work-in-progress but any > > > > feedbacks are welcome. > > > > > > Is there a good reason that this is implemented as a new kind of netdev > > > rather than just a new way for the existing netdev implementation to do > > > packet i/o? > > > > The AF_PACKET v3 is more like PMD mode driver (the netdev-afxdp and > > other dpdk netdev), which has its own memory mgmt, ring structure, and > > polling the descriptors. So I implemented it as a new kind. I feel its > > pretty different than tap or existing af_packet netdev. > > > > But integrate it to the existing netdev (lib/netdev-linux.c) is also OK. > > Do you think it's sufficiently different from a user's point of view? I > think that's probably an important point of view here. It's great if > the user can just suddenly get better performance without having to do > anything else. > > On the other hand, if the user might need to know that tpacket is in > use, like maybe if there is some downside or tradeoff to using it (for > example, it needs a ring--does that use a lot of memory and would that > be regrettable sometimes?), then that argues toward making it > configurable.
Good point. Let me spend more time on optimizing the patch's performance so I can better answer this question. > > You say it's more like afxdp. Maybe it should be a fallback for afxdp, > so that if afxdp isn't available for some reason then it automatically > uses tpacket itself. Or maybe that's a ridiculous idea for some > reason, I don't know. > > Do you think it is likely that a system supports tpacket but not afxdp? It's possible, before 5.0 kernel, there is no afxdp. So tpacket could be a good fallbck case. But the performance differs a lot based on this patch. William _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
