DPDK API/ABI Stability

DPDK API/ABI Stability

[Neil Horman]

Hey all-
	I was going to include this as an addendum to the packaging thread on
this list, but I can't seem to find it in my inbox, so forgive me starting a new
one.

	I wanted to broach the subject of ABI/API stability on the list here.
Given the recent great efforts to make dpdk packagable by disributions, I think
we probably need to discuss API stability in more depth and come up with a plan
to implement it.  Has anyone started looking into this?  If not, it seems to me
to be reasonable to start by placing a line in the sand with the functions
documented here:

http://dpdk.org/doc/api/

It seems to me we can start reviewing the API library by library, enusring only
those functions are exported, making sure the data types are appropriate for
export, and marking them with a linker script to version them appropriately.

Thoughts?

Neil

Re: DPDK API/ABI Stability

[Stephen Hemminger]

On Wed, 9 Apr 2014 14:39:52 -0400
Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote:

> Hey all-
> 	I was going to include this as an addendum to the packaging thread on
> this list, but I can't seem to find it in my inbox, so forgive me starting a new
> one.
> 
> 	I wanted to broach the subject of ABI/API stability on the list here.
> Given the recent great efforts to make dpdk packagable by disributions, I think
> we probably need to discuss API stability in more depth and come up with a plan
> to implement it.  Has anyone started looking into this?  If not, it seems to me
> to be reasonable to start by placing a line in the sand with the functions
> documented here:
> 
> http://dpdk.org/doc/api/
> 
> It seems to me we can start reviewing the API library by library, enusring only
> those functions are exported, making sure the data types are appropriate for
> export, and marking them with a linker script to version them appropriately.

To what level? source? binary, internal functions?

Some of the API's could be stablized without much impact but others such
as the device driver interface is incomplete and freezing it would make
live hard.

Re: DPDK API/ABI Stability

[Neil Horman]

On Wed, Apr 09, 2014 at 02:08:49PM -0700, Stephen Hemminger wrote:
> On Wed, 9 Apr 2014 14:39:52 -0400
> Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote:
> 
> > Hey all-
> > 	I was going to include this as an addendum to the packaging thread on
> > this list, but I can't seem to find it in my inbox, so forgive me starting a new
> > one.
> > 
> > 	I wanted to broach the subject of ABI/API stability on the list here.
> > Given the recent great efforts to make dpdk packagable by disributions, I think
> > we probably need to discuss API stability in more depth and come up with a plan
> > to implement it.  Has anyone started looking into this?  If not, it seems to me
> > to be reasonable to start by placing a line in the sand with the functions
> > documented here:
> > 
> > http://dpdk.org/doc/api/
> > 
> > It seems to me we can start reviewing the API library by library, enusring only
> > those functions are exported, making sure the data types are appropriate for
> > export, and marking them with a linker script to version them appropriately.
> 
> To what level? source? binary, internal functions?
> 
Well, I was thinking both (hence the API/ABI comment above), but at least API
stability as a start.  Stabilizing internal functions doesn't make any sense to
me since, by definition those aren't exposed to users trying to make use of the
library.

> Some of the API's could be stablized without much impact but others such
> as the device driver interface is incomplete and freezing it would make
> live hard.

But the driver interface isn't listed on the api documentation above.  Clearly
we'd need to address that eventually, but as a start it can likely be ignored,
at least we can give applications a modicum of stability.

Neil

Poor device abstraction's

[Stephen Hemminger]

One of my pet peeve's is that the device driver config does not abstract
the properties of the Ethernet device. The existing parameters match those
of Intel's Ethernet hardware but not much else. It also makes it hard
to write generic applications.  If the application has to query the
device driver name string and insert different parameters for igb, igbvf, ixgbe
and vmxnet3 then the API was designed wrong.

Specific examples:
  * the "descriptors" argument to rx/tx is interpreted as a hardware resource
    not the number of packets. An application really wants to say "you may buffer
    up to 100us of packets" not have to guess what the underlying driver does.

  * the rthresh/wthresh/pthresh are PCI device artifacts and correct value is
    different for each HW device shouldn't be exposed to application. The API
    should be something like "device may burst up to N packets and/or T latency".

These seems like issues of a transition from a cool toy to talk to Intel hardware
to a useful application infrastructure.

That is why I would hate to see the existing Intel device centric API frozen.

Re: Poor device abstraction's

[Neil Horman]

On Fri, Apr 11, 2014 at 10:33:31AM -0700, Stephen Hemminger wrote:
> One of my pet peeve's is that the device driver config does not abstract
> the properties of the Ethernet device. The existing parameters match those
> of Intel's Ethernet hardware but not much else. It also makes it hard
> to write generic applications.  If the application has to query the
> device driver name string and insert different parameters for igb, igbvf, ixgbe
> and vmxnet3 then the API was designed wrong.
> 
I agree.  I think the patches that recently got integrated from Olivier are a
step toward fixing that, but theres some more work to be done.

Neil

> Specific examples:
>   * the "descriptors" argument to rx/tx is interpreted as a hardware resource
>     not the number of packets. An application really wants to say "you may buffer
>     up to 100us of packets" not have to guess what the underlying driver does.
> 
>   * the rthresh/wthresh/pthresh are PCI device artifacts and correct value is
>     different for each HW device shouldn't be exposed to application. The API
>     should be something like "device may burst up to N packets and/or T latency".
> 
> These seems like issues of a transition from a cool toy to talk to Intel hardware
> to a useful application infrastructure.
> 
> That is why I would hate to see the existing Intel device centric API frozen.
> 

Re: Poor device abstraction's

[Venkatesan, Venky]

Agree that the patch sets are a step towards fixing that, but there is a lot more to be done on this. Could we start discussion on what the "ideal" abstraction should be? I'd like to pool those into a formal proposal that we can discuss and drive through a series of patches to make that happen. Even semi-freezing anything prior to that would be premature. 

-Venky

-----Original Message-----
From: dev [mailto:dev-bounces-VfR2kkLFssw@public.gmane.org] On Behalf Of Neil Horman
Sent: Friday, April 11, 2014 10:47 AM
To: Stephen Hemminger
Cc: dev-VfR2kkLFssw@public.gmane.org
Subject: Re: [dpdk-dev] Poor device abstraction's

On Fri, Apr 11, 2014 at 10:33:31AM -0700, Stephen Hemminger wrote:
> One of my pet peeve's is that the device driver config does not 
> abstract the properties of the Ethernet device. The existing 
> parameters match those of Intel's Ethernet hardware but not much else. 
> It also makes it hard to write generic applications.  If the 
> application has to query the device driver name string and insert 
> different parameters for igb, igbvf, ixgbe and vmxnet3 then the API was designed wrong.
> 
I agree.  I think the patches that recently got integrated from Olivier are a step toward fixing that, but theres some more work to be done.

Neil

> Specific examples:
>   * the "descriptors" argument to rx/tx is interpreted as a hardware resource
>     not the number of packets. An application really wants to say "you may buffer
>     up to 100us of packets" not have to guess what the underlying driver does.
> 
>   * the rthresh/wthresh/pthresh are PCI device artifacts and correct value is
>     different for each HW device shouldn't be exposed to application. The API
>     should be something like "device may burst up to N packets and/or T latency".
> 
> These seems like issues of a transition from a cool toy to talk to 
> Intel hardware to a useful application infrastructure.
> 
> That is why I would hate to see the existing Intel device centric API frozen.
> 

Re: Poor device abstraction's

[Neil Horman]

On Fri, Apr 11, 2014 at 05:57:41PM +0000, Venkatesan, Venky wrote:
> Agree that the patch sets are a step towards fixing that, but there is a lot more to be done on this. Could we start discussion on what the "ideal" abstraction should be? I'd like to pool those into a formal proposal that we can discuss and drive through a series of patches to make that happen. Even semi-freezing anything prior to that would be premature. 
> 
Well, just to throw something out there, what about starting with the net_device
structure in the kernel, and removing things that are unnecessecary?  That might
give us a good starting point to see what else is needed
Neil

> -Venky
> 
> -----Original Message-----
> From: dev [mailto:dev-bounces-VfR2kkLFssw@public.gmane.org] On Behalf Of Neil Horman
> Sent: Friday, April 11, 2014 10:47 AM
> To: Stephen Hemminger
> Cc: dev-VfR2kkLFssw@public.gmane.org
> Subject: Re: [dpdk-dev] Poor device abstraction's
> 
> On Fri, Apr 11, 2014 at 10:33:31AM -0700, Stephen Hemminger wrote:
> > One of my pet peeve's is that the device driver config does not 
> > abstract the properties of the Ethernet device. The existing 
> > parameters match those of Intel's Ethernet hardware but not much else. 
> > It also makes it hard to write generic applications.  If the 
> > application has to query the device driver name string and insert 
> > different parameters for igb, igbvf, ixgbe and vmxnet3 then the API was designed wrong.
> > 
> I agree.  I think the patches that recently got integrated from Olivier are a step toward fixing that, but theres some more work to be done.
> 
> Neil
> 
> > Specific examples:
> >   * the "descriptors" argument to rx/tx is interpreted as a hardware resource
> >     not the number of packets. An application really wants to say "you may buffer
> >     up to 100us of packets" not have to guess what the underlying driver does.
> > 
> >   * the rthresh/wthresh/pthresh are PCI device artifacts and correct value is
> >     different for each HW device shouldn't be exposed to application. The API
> >     should be something like "device may burst up to N packets and/or T latency".
> > 
> > These seems like issues of a transition from a cool toy to talk to 
> > Intel hardware to a useful application infrastructure.
> > 
> > That is why I would hate to see the existing Intel device centric API frozen.
> > 
>