[dpdk-dev] [PATCH 02/10] examples/test-cxgbe-filters: add example to test cxgbe fdir support

[Bruce Richardson]

On Thu, Feb 25, 2016 at 12:05:34AM +0530, Rahul Lakkireddy wrote:
> Hi Bruce,
> 
> On Wednesday, February 02/24/16, 2016 at 06:40:56 -0800, Bruce Richardson wrote:
> > On Wed, Feb 03, 2016 at 02:02:23PM +0530, Rahul Lakkireddy wrote:
> > > Add a new test_cxgbe_filters command line example to test support for
> > > Chelsio T5 hardware filtering. Shows how to pass the Chelsio input flow
> > > and input masks. Also, shows how to pass extra behavior arguments to
> > > rewrite fields in matched filter rules.
> > > 
> > > Also add documentation and update MAINTAINERS.
> > > 
> > > Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy at chelsio.com>
> > > Signed-off-by: Kumar Sanghvi <kumaras at chelsio.com>
> > 
> > Hi,
> > 
> > for testing NIC functionality, the "testpmd" app is what is used, and it already
> > contains support for existing flow director functionality. Should the testing
> > functionality not be included there?
> > 
> 
> We initially thought of adding example by extending flow director in
> testpmd itself.  However, based on discussion at [1], we then created
> a separate sample app for this considering each vendor would come up
> with their own sample app.
> 
> [1] http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/31471
>

Thanks for the old conversation link. I don't like the idea of having vendor
specific sample apps, I think the samples should be as generic as possible. If
there is a particular feature that you want to demonstrate in a sample app, then
that is worthy of inclusion - assuming it's possible that in future more than
one vendor's hardware will support the feature.

Within the documentation for the particular NIC or driver, feel free to call out
what features the NIC supports and how those should be configured.

I hope this makes sense. We probably need a documented policy on how to go
about adding new NIC feature support to ensure everyone is in agreement on how
things should be done so as to allow vendors to expose the features of their
hardware, while at the same time allowing users to write applications that can
be generic across the various hardware platforms.

Regards,
/Bruce