Re: [dpdk-dev] mlx5 under FreeBSD

[Stephen Hemminger <stephen@networkplumber.org>]

On Mon, 19 Nov 2018 09:09:22 -0600 (CST)
Mit Matelske <mit@pt.net> wrote:

> > Monday, November 19, 2018 1:23 AM, Mit Matelske:  
> >> Subject: Re: [dpdk-dev] mlx5 under FreeBSD
> >>   
> >> > 15/11/2018 17:48, Mit Matelske:  
> >> >> Is anyone working to include support for the mlx5 PMD under FreeBSD?  
> >> >
> >> > I think Stephen (Cc) looked at it.
> >> >  
> >> >> I've started down this road by building Linux compatibility layers
> >> >> for the required Netlink and Ethtool calls in the driver, but would
> >> >> gladly accept help and advice from those much more knowledgeable then  
> >> myself!  
> > 
> > Are you sure netlink and ioctl is all you need?
> > Looks like also sysfs stuff, and I am not sure what else is missing from the
> > DPDK eal layer, the FreeBSD has many not supported functions.  
> 
> No, I'm not sure of anything.  I've just started focusing on this.  I do know to
> get it to compile I had to include subsets the following includes:
> 
> libmnl/libmnl.h
> linux/ethtool.h
> linux/netlink.h
> linux/neighbour.h
> linux/types.h
> linux/rtnetlink.h
> linux/pkt_cls.h
> linux/pkt_sched.h
> linux/if_ether.h
> linux/tc_act/tc_gact.h
> linux/tc_act/tc_mirred.h
> 
> My initial goal is to change the DPDK code as little as possible, but that
> might not be be possible.  You'd have a much better feel for that than me
> at this point.
> 
> > 
> > We haven't started to work on it because the majority of our use cases are for
> > Linux.   
> 
> I figured as much.  
> 
> > Nevertheless, we can help with code reviews and guidance.  
> 
> Once I get somewhere I will definitely take you up on that.
> 
> Thanks!
> 
> Mit
> 
> >   
> >> >
> >> > Cc also mlx5 maintainers.  
> >> 
> >> Thomas-
> >> 
> >> Thanks for looping the correct people in!
> >>   
> >> >  
> >> >> Though not important, why did Mellanox build a PMD that relied on the
> >> >> kernel driver being in place unlike most other PMDs?  
> >> >
> >> > Because it allows to choose which flows go to DPDK and which ones are
> >> > processed by the kernel.
> >> > Actually, you should ask why other PMDs don't have this feature ;)  
> > 
> > +1.
> >   
> >> 
> >> Very fair response.  We actually wrote our own "shim" into the stack for all
> >> the relevant drivers we use to both keep the existing ifnet interfaces around
> >> and to pass packets to and from the stack from every interface.
> >> 
> >> Your comment matches one of my co-worker's when I explained to him how
> >> the mlx5 driver works.
> >> 
> >> Mit
> >>  

Rather than building a complex shim, why not just have an OS dependent section
of the driver.  The bigger issue is that the kernel side functionality in BSD
is different or missing.  For example TAP API is different and not multi-queue.