On Thu, 9 Mar 2017 15:29:01 +0000 Ferruh Yigit <ferruh.yi...@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.ma...@6wind.com> > > Acked-by: Olga Shern <ol...@mellanox.com> > <...>
