[dpdk-dev] [RFC PATCH 4/4] ethdev: add helpers to move to the new offloads API

[Ananyev, Konstantin]

Hi Ferruh,

> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Wednesday, August 30, 2017 8:51 AM
> To: Shahaf Shuler <shahafs at mellanox.com>; Thomas Monjalon <thomas at monjalon.net>; Ananyev, Konstantin
> <konstantin.ananyev at intel.com>
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [RFC PATCH 4/4] ethdev: add helpers to move to the new offloads API
> 
> On 8/30/2017 7:30 AM, Shahaf Shuler wrote:
> > Tuesday, August 29, 2017 3:55 PM, Ferruh Yigit:
> >>>> Considering the re-configuration is risky, and without other ideas I will
> >> need to fall back to the error flow case.
> >>>> Are we OK with that?
> >>>
> >>> I think we can take the risk of keeping this call to
> >>> rte_eth_dev_configure() in the middle of rte_eth_rx_queue_setup().
> >>> In theory it should be acceptable.
> >>> If we merge it soon, it can be better tested with every drivers.
> >>
> >> I doubt about taking that risk. Some driver does HW configuration via
> >> configure() and combination of start/stop, setup_queue and configure can
> >> be complex.
> >>
> >> I am for generating error for this case.
> >>
> >> Generating error also can be good motivation for PMDs to adapt new
> >> method.
> >
> > Adding Ananyev suggestion from other thread:
> > For tx_prepare() work, we used the following approach:
> > 1. submitted patch with changes in rte_ethdev and PMDs we  are familiar with (Intel ones).
> >     For other PMDs - patch contained just minimal changes to make it build cleanly.
> > 2. Asked other PMD maintainers to review rte_ethdev changes and provide a proper patch
> >     for the PMD they own.
> 
> tx_prepare() is a little different, since it was not clear if all PMDs
> needs updating that is why asked to PMD owners, and the ones requires
> updating already has been updated with ethdev patch. Here we know all
> PMDs need updating, and they need proper time in advance.
> 
> >
> > So I am OK with both suggestions. Meaning:
> > 1. Define the case were application use the new offloads API with PMD which supports the old one as an error.
> > 2. apply patches to ethdev with the above behavior.
> >
> > Just to emphasize, it means that PMDs which won't move to the new API by the end of 17.11 will not be able to run with any of the
> examples and application on DPDK tree (and also with other applications which moved to the new API), as I plan to submit patches which
> convert them all to the new API.
> 
> I think it is good idea to update samples/apps to new method, but this
> can be short notice for PMD owners.
> 
> Can we wait one more release to update samples/apps, to give time for
> PMDs to be updated, since old applications will work with new PMDs
> (thanks to your helpers), I believe this won't be a problem.

I am not sure what is your suggestion here?
Support both flavors of PMD API for 17.11? 
Konstantin

> 
> >
> > Any objection to this approach?
> >
> >