[ovs-dev] [PATCH RFC] WIP: netdev-tpacket: Add AF_PACKET v3 support.

Ben Pfaff blp at ovn.org
Fri Dec 20 21:14:37 UTC 2019


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.

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?

Thanks,

Ben.


More information about the dev mailing list