From: "Nambiar, Amritha" <amritha.nambiar@intel.com>
To: Jamal Hadi Salim <jhs@mojatatu.com>,
intel-wired-lan@lists.osuosl.org, jeffrey.t.kirsher@intel.com
Cc: alexander.h.duyck@intel.com, jiri@resnulli.us,
netdev@vger.kernel.org, alexander.duyck@gmail.com,
xiyou.wangcong@gmail.com
Subject: Re: [jkirsher/next-queue PATCH v4 0/6] tc-flower based cloud filters in i40e
Date: Wed, 11 Oct 2017 15:41:20 -0700 [thread overview]
Message-ID: <6ce79435-e3fb-9a34-b48f-0f61d53cd52b@intel.com> (raw)
In-Reply-To: <f85aa039-cf16-a25a-5b60-1af747b44f62@mojatatu.com>
On 10/11/2017 5:42 AM, Jamal Hadi Salim wrote:
> On 17-10-10 08:24 PM, Amritha Nambiar wrote:
>> This patch series enables configuring cloud filters in i40e
>> using the tc-flower classifier. The classification function
>> of the filter is to match a packet to a class. cls_flower is
>> extended to offload classid to hardware. The offloaded classid
>> is used direct matched packets to a traffic class on the device.
>> The approach here is similar to the tc 'prio' qdisc which uses
>> the classid for band selection. The ingress qdisc is called ffff:0,
>> so traffic classes are ffff:1 to ffff:8 (i40e has max of 8 TCs).
>> TC0 is minor number 1, TC1 is minor number 2 etc.
>>
>> The cloud filters are added for a VSI and are cleaned up when
>> the VSI is deleted. The filters that match on L4 ports needs
>> enhanced admin queue functions with big buffer support for
>> extended fields in cloud filter commands.
>>
>> Example:
>> # tc qdisc add dev eth0 ingress
>> # ethtool -K eth0 hw-tc-offload on
>>
>> Match Dst IPv4,Dst Port and route to TC1:
>> # tc filter add dev eth0 protocol ip parent ffff: prio 1 flower\
>> dst_ip 192.168.1.1/32 ip_proto udp dst_port 22\
>> skip_sw classid ffff:2
>>
>> # tc filter show dev eth0 parent ffff:
>> filter pref 1 flower chain 0
>> filter pref 1 flower chain 0 handle 0x1 classid ffff:2
>> eth_type ipv4
>> ip_proto udp
>> dst_ip 192.168.1.1
>> dst_port 22
>> skip_sw
>> in_hw
>>
>
> Much much better semantic. Thank you.
> Have you tested many filter mapping to the same classid?
Yes, I have tested mapping different filters to the same classID,
packets matching the flows were assigned the same classID and routed to
the same traffic class in HW.
filter pref 1 flower chain 0
filter pref 1 flower chain 0 handle 0x1 classid ffff:2
dst_mac 3c:fd:fe:a0:d6:70
eth_type ipv4
ip_proto udp
dst_port 12000
in_hw
filter pref 5 flower chain 0
filter pref 5 flower chain 0 handle 0x1 classid ffff:2
eth_type ipv4
ip_proto udp
dst_ip 192.168.1.1
dst_port 12000
in_hw
>
> cheers,
> jamal
>
next prev parent reply other threads:[~2017-10-11 22:41 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-11 0:24 [jkirsher/next-queue PATCH v4 0/6] tc-flower based cloud filters in i40e Amritha Nambiar
2017-10-11 0:24 ` [jkirsher/next-queue PATCH v4 1/6] cls_flower: Offload classid to hardware Amritha Nambiar
2017-10-11 0:24 ` [jkirsher/next-queue PATCH v4 2/6] i40e: Map TCs with the VSI seids Amritha Nambiar
2017-10-11 0:24 ` [jkirsher/next-queue PATCH v4 3/6] i40e: Cloud filter mode for set_switch_config command Amritha Nambiar
2017-10-11 23:30 ` [Intel-wired-lan] " Shannon Nelson
2017-10-26 21:10 ` Nambiar, Amritha
2017-10-11 0:24 ` [jkirsher/next-queue PATCH v4 4/6] i40e: Admin queue definitions for cloud filters Amritha Nambiar
2017-10-11 23:30 ` [Intel-wired-lan] " Shannon Nelson
2017-10-11 0:24 ` [jkirsher/next-queue PATCH v4 5/6] i40e: Clean up of " Amritha Nambiar
2017-10-11 23:30 ` [Intel-wired-lan] " Shannon Nelson
2017-10-11 0:24 ` [jkirsher/next-queue PATCH v4 6/6] i40e: Enable cloud filters via tc-flower Amritha Nambiar
2017-10-11 23:30 ` [Intel-wired-lan] " Shannon Nelson
2017-10-26 21:29 ` Nambiar, Amritha
2017-10-26 21:35 ` Shannon Nelson
2017-10-26 21:47 ` Nambiar, Amritha
2017-10-11 12:42 ` [jkirsher/next-queue PATCH v4 0/6] tc-flower based cloud filters in i40e Jamal Hadi Salim
2017-10-11 22:41 ` Nambiar, Amritha [this message]
2017-10-11 12:56 ` Jiri Pirko
2017-10-11 17:46 ` Alexander Duyck
2017-10-11 20:38 ` Jiri Pirko
2017-10-11 20:46 ` David Miller
2017-10-11 20:58 ` Jiri Pirko
2017-10-11 21:19 ` David Miller
2017-10-11 21:28 ` Jiri Pirko
2017-10-12 7:05 ` Alexander Duyck
2017-10-12 7:30 ` Jiri Pirko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6ce79435-e3fb-9a34-b48f-0f61d53cd52b@intel.com \
--to=amritha.nambiar@intel.com \
--cc=alexander.duyck@gmail.com \
--cc=alexander.h.duyck@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).