On Wed, Oct 14, 2015 at 04:36:27PM +0200, Vincent JARDIN wrote: > Thomas, John, > > thanks for your notes. > > Enclosed the contents of our chats, > > On 13/10/2015 18:36, Mcnamara, John wrote: > >* PMD lite > > > > - Do we need a lighter PMD model? Perhaps based on the Mellanox > > model. > > - Vincent suggested be could remove 90% of the code. I'll leave > > Vincent explain this one. > > benefits of 100% userland drivers: > - no dependency on getting kernel patch upstreams first > - it is possible to run on a latest HW even when the Linux host (or host > OS) does not support the new NIC/boards supported by the DPDK > > drawbacks of 100% userland drivers: > - redundancy of source code (duplication into the kernel and userland) > => more maintenance > - DPDK PMDs are in fact outdated while kernel drivers are supporting > latest HW (port management - optics - , latest HW revisions, managing > firmware updates) more frequently > - do not run when not root applications > - cannot reuse port management tools from the kernels (ethtool, etc.) > > ixgbe pmd > ========= > 100% lines of userland > must be run as root > ~ 40K lines > ~ kernel overlaps with > http://dpdk.org/browse/dpdk/tree/drivers/net/ixgbe/base > ~ mostly only > http://dpdk.org/browse/dpdk/tree/drivers/net/ixgbe/ixgbe_rxtx[_vec].c is > needed, other files are not needed (6k lines of code) > > mlx4 pmd > ======== > 10% lines userland, then using kernel's ones > could be run as a non root process > ~ 5.2K lines of code > ~ the rxtx.c file is http://dpdk.org/browse/dpdk/tree/drivers/net/mlx4/ > BUT using infiniband :( => should be cleand up to use bare minimum like, > + /* Allocate protection domain. */ > http://dpdk.org/browse/dpdk/tree/drivers/net/mlx4/mlx4.c#n4828 > > + Register memory regions -> ibv_reg_mr() > http://dpdk.org/browse/dpdk/tree/drivers/net/mlx4/mlx4.c#n792 > > Best regards, > Vincent
Hi Vincent, is the approach described for the mlx4 driver not dependent upon the hardware having support for infiniband verbs, in which case I don't see how it could be used for other NICs. Has an attempt been made to create a driver for another NIC family using this approach to prove it is generally applicable? /Bruce
