[dpdk-dev] DPDK User Space: Session onUseability and Ease of Use
Bruce Richardson
bruce.richardson at intel.com
Wed Oct 14 18:34:19 CEST 2015
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
More information about the dev
mailing list