Re: [dpdk-dev] DPDK User Space: Session onUseability and Ease of Use

[Bruce Richardson <bruce.richardson@intel.com>]

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