[dpdk-dev] [PATCH v3 3/4] net/tap: add netlink back-end for flow API

Pascal Mazon pascal.mazon at 6wind.com
Fri Mar 10 10:39:01 CET 2017


On Thu, 9 Mar 2017 15:29:01 +0000
Ferruh Yigit <ferruh.yigit at intel.com> wrote:

> On 3/7/2017 4:35 PM, Pascal Mazon wrote:
> > Each kernel netdevice may have queueing disciplines set for it,
> > which determine how to handle the packet (mostly on egress). That's
> > part of the TC (Traffic Control) mechanism.
> 
> This is nice.
> qdisc is egress part of the network stack right, is there any ingress
> part of it?
> 

qdisc is mainly for egress (can range from 0 to fffe), but there is one
qdisc for ingress (ffff).

> > 
> > Through TC, it is possible to set filter rules that match specific
> > packets, and act according to what is in the rule. This is a perfect
> > candidate to implement the flow API for the tap PMD, as it has an
> > associated kernel netdevice automatically.
> > 
> > Each flow API rule will be translated into its TC counterpart.
> 
> What can be use cases here?

Well, it can be any case with rte_flow. Such as directing incoming
packets to specific queues for the application, dropping them, and any
kind of filtering (along those supported, see later patch).

> 
> > 
> > To leverage TC, it is necessary to communicate with the kernel using
> > netlink. This patch introduces a library to help that communication.
> > 
> 
> What do you think implementing these out of tap PMD? These can be used
> by KNI too.
> 

Well, I don't know about KNI, but I think setting it in tap PMD, which
is the current sole user for this, is a good start.
It will always be time later to make it more generic for other uses.

Regards,
Pascal

> > Inside netlink.c, functions are generic for any netlink messaging.
> > Inside tcmsgs.c, functions are specific to deal with TC rules.
> > 
> > Signed-off-by: Pascal Mazon <pascal.mazon at 6wind.com>
> > Acked-by: Olga Shern <olgas at mellanox.com>
> <...>



More information about the dev mailing list