Re: [dpdk-dev] [PATCH 1/4] lib/librte_ether: new filter APIs definition

[Thomas Monjalon <thomas.monjalon@6wind.com>]

2014-10-10 07:28, De Lara Guarch, Pablo:
> > > > > Define new APIs to support configure multi-kind filters using same
> > > > > APIs
> > > > >  - rte_eth_dev_filter_supported
> > > > >  - rte_eth_dev_filter_ctrl
> > > > >
> > > > > As to the implemetation discussion, please refer to
> > > > > http://dpdk.org/ml/archives/dev/2014-September/005179.html, and
> > > > > control packet filter implementation is based on it.
> > > >
> > > > This patch is also present on the patchset Support flow director
> > > > programming on Fortville.
> > > > Should this patchset be rejected then or just this patch? In second
> > > > case, could you send a v2 without this patch?
> > >
> > > I think this patch does not only present on the flow director patchset, but
> > > also on mac vlan support patchset, vxlan patchset, and so on. All of them
> > are
> > > using the same new filter APIs. If any patchset is applied, others may
> > require
> > > some modification (just as you said to remove this pacth).
> > >
> > Additional, without the patch, this patchset cannot work separately. More
> > than one features depend on the new filter APIs, but none patchset contains
> > the new filter APIs is applied currently.  That's why each patchset has such
> > patch.
> 
> I see, then probably the best idea would have been send this patch separately,
>  and just say that these patchsets depend on this patch, basically because
>  if you try to apply all these patches, you are going to get failures.

Yes, sending a separated patch and explicitly base your patch on this one
would be really easier to understand. And more generally, it's easier when
things are explained. You won't have to pay for the extra words you put in
your cover letter ;)

There is another problem with this patch: there are many versions around with
different logs and even different authors!

-- 
Thomas