Hi Ferruh,

On Thu, Apr 20, 2017 at 07:54:47PM +0100, Ferruh Yigit wrote:
DPDK works with packets, but some network administration tools works based on
flow information.

This library is suggested to provide helper APIs to convert packet based
information to the flow records. Library header file has more comments on
how library works and provided APIs.

Packets to flow conversion will cause performance drop, that is why this
conversion can be enabled and disabled dynamically by application.

Initial implementation in mind is to provide support for IPFIX metering process
but library planned to be as generic as possible. And flow information provided
by this library is missing to implement full IPFIX features, but this is planned
to be initial step.


In order to be generic, would it not be interesting to specify the flow
as a generic rte_flow_item list? Some specific IPFIX items are not
expressed currently in rte_flow (e.g. packet size), but they could be added.

This library could consist in an rte_flow_item to IPFIX translation.

The inverse approach could be used, but seems backward to me. It makes
more sense to support DPDK idioms and open them to standards by
proper APIs than including standards in internals and introduce
translation layers between DPDK components.

It is possible to define flow with various flow keys, but currently only one
type of flow defined in the library, which is more generic, and it offloads
fine grained flow analysis to the application. Library enables expanding for
other flow types.


I'm not sure I understand the purpose of this flow key, generic
is too general of a hint to define the possible cases.

However, my intuition is that the flow type describe a filter to
restrict the flow classification to specific patterns instead of all
supported ones.

This library thus resembles using the action RTE_FLOW_ACTION_TYPE_COUNT, then
retrieved using rte_flow_query_count. The rte_flow_item aggregated with
the rte_flow_query_count structure could be sufficient to derive IPFIX
meters?

An application could then use this data for its IPFIX support.

It will be more beneficial to shape this library to cover more use cases, please
feel free to comment on possible other use case and desired functionalities.

Thanks,
ferruh

cc: John McNamara <john.mcnam...@intel.com>
cc: Maryam Tahhan <maryam.tah...@intel.com>

Ferruh Yigit (1):
 flow_classify: add librte_flow_classify library

config/common_base                                 |   5 +
doc/api/doxy-api-index.md                          |   1 +
doc/api/doxy-api.conf                              |   1 +
doc/guides/rel_notes/release_17_05.rst             |   1 +
lib/Makefile                                       |   2 +
lib/librte_flow_classify/Makefile                  |  50 +++++
lib/librte_flow_classify/rte_flow_classify.c       |  34 ++++
lib/librte_flow_classify/rte_flow_classify.h       | 202 +++++++++++++++++++++
.../rte_flow_classify_version.map                  |  10 +
9 files changed, 306 insertions(+)
create mode 100644 lib/librte_flow_classify/Makefile
create mode 100644 lib/librte_flow_classify/rte_flow_classify.c
create mode 100644 lib/librte_flow_classify/rte_flow_classify.h
create mode 100644 lib/librte_flow_classify/rte_flow_classify_version.map

--
2.9.3


--
Gaëtan Rivet
6WIND

Reply via email to