Re: [PATCH v2 2/7] ethdev: define new ethdev API rx_classification_filter_ctl

[Thomas Monjalon <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>]

2014-08-28 13:39, Wu, Jingjing:
> From: Thomas Monjalon [mailto:thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org]
> > I'm OK to change APIs but you should remove the old one, or at least,
> > implement your new API in existing drivers to allow deprecation of the
> > old API.
> > I think it would help if you start by doing ixgbe work and then apply it
> > to i40e.
> > 
> 
> Yes, it will be perfect if we can use this new API to achieve flow director 
> setting all types of NICs. But the concern is downward compatibility.

In this case, cleanup is more important than compatibility.

> Users who is planning update DPDK version need to change their code
> to adapt such changes.

Yes, but we can keep deprecated function during 1 release.

> That's why we choose a new API instead of modifying current APIs. And 
> Of course, the ideal plan is adding such XXX_ctl function in Ixgbe and
> Igb to moving smoothly without removing current APIs.

Yes

> > I don't think flow director is a specific feature. We shouldn't have
> > to care if port is i40e or ixgbe to setup flow director.
> > Is it possible to have a common API and maybe an inheritance of the
> > common structure with PMD specific fields?
> 
> Yes, flow director is not a specific feature. Even ixgbe and i40 use the same 
> name. But the context and key have much difference. That's why I called it
> specific.
> 
> Yes, it's a good idea about an inheritance of the common structure. I think it
> may support new NIC integration in future. We can do it with the new API 
> architecture. But the concern is still how to be compatible with old version.

There is no compatibility blocker here.
If we can keep deprecated functions a while, we'll do. Otherwise, just go with
the new API.
I prefer we concentrate on good design rather than on compatibility.

Thanks
-- 
Thomas