[jkirsher/next-queue,v4,0/6] tc-flower based cloud filters in i40e

Message ID 150768099999.5320.1633617713417675266.stgit@anamdev.jf.intel.com
Headers show
Series
  • tc-flower based cloud filters in i40e
Related show

Message

Nambiar, Amritha Oct. 11, 2017, 12:24 a.m.
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

v4: classid based approach to set traffic class for matched packets.

Authors:
Amritha Nambiar <amritha.nambiar@intel.com>
Kiran Patil <kiran.patil@intel.com>
Anjali Singhai Jain <anjali.singhai@intel.com>
Jingjing Wu <jingjing.wu@intel.com>
---

Amritha Nambiar (6):
      cls_flower: Offload classid to hardware
      i40e: Map TCs with the VSI seids
      i40e: Cloud filter mode for set_switch_config command
      i40e: Admin queue definitions for cloud filters
      i40e: Clean up of cloud filters
      i40e: Enable cloud filters via tc-flower


 drivers/net/ethernet/intel/i40e/i40e.h             |   55 +
 drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h  |  143 +++
 drivers/net/ethernet/intel/i40e/i40e_common.c      |  193 ++++
 drivers/net/ethernet/intel/i40e/i40e_ethtool.c     |    2 
 drivers/net/ethernet/intel/i40e/i40e_main.c        |  941 +++++++++++++++++++-
 drivers/net/ethernet/intel/i40e/i40e_prototype.h   |   18 
 drivers/net/ethernet/intel/i40e/i40e_type.h        |   10 
 .../net/ethernet/intel/i40evf/i40e_adminq_cmd.h    |  113 ++
 include/net/pkt_cls.h                              |    1 
 net/sched/cls_flower.c                             |    2 
 10 files changed, 1439 insertions(+), 39 deletions(-)

--

Comments

Jamal Hadi Salim Oct. 11, 2017, 12:42 p.m. | #1
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?

cheers,
jamal
Jiri Pirko Oct. 11, 2017, 12:56 p.m. | #2
Wed, Oct 11, 2017 at 02:24:12AM CEST, amritha.nambiar@intel.com 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).


NACK. This clearly looks like abuse of classid to something
else. Classid is here to identify qdisc instance. However, you use it
for hw tclass identification. This is mixing of apples and oranges.

Why?

Please don't try to abuse things! This is not nice.




>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
>
>v4: classid based approach to set traffic class for matched packets.
>
>Authors:
>Amritha Nambiar <amritha.nambiar@intel.com>
>Kiran Patil <kiran.patil@intel.com>
>Anjali Singhai Jain <anjali.singhai@intel.com>
>Jingjing Wu <jingjing.wu@intel.com>
>---
>
>Amritha Nambiar (6):
>      cls_flower: Offload classid to hardware
>      i40e: Map TCs with the VSI seids
>      i40e: Cloud filter mode for set_switch_config command
>      i40e: Admin queue definitions for cloud filters
>      i40e: Clean up of cloud filters
>      i40e: Enable cloud filters via tc-flower
>
>
> drivers/net/ethernet/intel/i40e/i40e.h             |   55 +
> drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h  |  143 +++
> drivers/net/ethernet/intel/i40e/i40e_common.c      |  193 ++++
> drivers/net/ethernet/intel/i40e/i40e_ethtool.c     |    2 
> drivers/net/ethernet/intel/i40e/i40e_main.c        |  941 +++++++++++++++++++-
> drivers/net/ethernet/intel/i40e/i40e_prototype.h   |   18 
> drivers/net/ethernet/intel/i40e/i40e_type.h        |   10 
> .../net/ethernet/intel/i40evf/i40e_adminq_cmd.h    |  113 ++
> include/net/pkt_cls.h                              |    1 
> net/sched/cls_flower.c                             |    2 
> 10 files changed, 1439 insertions(+), 39 deletions(-)
>
>--
Alexander Duyck Oct. 11, 2017, 5:46 p.m. | #3
On Wed, Oct 11, 2017 at 5:56 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> Wed, Oct 11, 2017 at 02:24:12AM CEST, amritha.nambiar@intel.com 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).
>
>
> NACK. This clearly looks like abuse of classid to something
> else. Classid is here to identify qdisc instance. However, you use it
> for hw tclass identification. This is mixing of apples and oranges.
>
> Why?
>
> Please don't try to abuse things! This is not nice.

This isn't an abuse. This is reproducing in hardware what is already
the behavior for software. Isn't that how offloads are supposed to
work?

This is exactly how prio currently handles this. We are essentially
doing the exact same thing in the hardware where we are choosing a
queueing group based on the class ID. You could setup a prio qdisc. If
you are offloading a qdisc behavior into hardware how are you supposed
to emulate the behavior if you aren't allowing the offload to use the
same mechanism?

- Alex
Jiri Pirko Oct. 11, 2017, 8:38 p.m. | #4
Wed, Oct 11, 2017 at 07:46:27PM CEST, alexander.duyck@gmail.com wrote:
>On Wed, Oct 11, 2017 at 5:56 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Wed, Oct 11, 2017 at 02:24:12AM CEST, amritha.nambiar@intel.com 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).
>>
>>
>> NACK. This clearly looks like abuse of classid to something
>> else. Classid is here to identify qdisc instance. However, you use it
>> for hw tclass identification. This is mixing of apples and oranges.
>>
>> Why?
>>
>> Please don't try to abuse things! This is not nice.
>
>This isn't an abuse. This is reproducing in hardware what is already
>the behavior for software. Isn't that how offloads are supposed to
>work?

What is meaning of classid in HW? Classid is SW only identification of
qdisc instances. No relation to HW instances = abuse.


>
>This is exactly how prio currently handles this. We are essentially
>doing the exact same thing in the hardware where we are choosing a
>queueing group based on the class ID. You could setup a prio qdisc. If
>you are offloading a qdisc behavior into hardware how are you supposed
>to emulate the behavior if you aren't allowing the offload to use the
>same mechanism?

I believe that the correct way to solve is to introduce SETTCLASS
termination action (similar to TRAP, GOTO_CHAIN, etc), which would allow
user to instruct the destination tclass and driver can offload it.
David Miller Oct. 11, 2017, 8:46 p.m. | #5
From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 11 Oct 2017 22:38:32 +0200

> Wed, Oct 11, 2017 at 07:46:27PM CEST, alexander.duyck@gmail.com wrote:
>>On Wed, Oct 11, 2017 at 5:56 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>> Wed, Oct 11, 2017 at 02:24:12AM CEST, amritha.nambiar@intel.com 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).
>>>
>>>
>>> NACK. This clearly looks like abuse of classid to something
>>> else. Classid is here to identify qdisc instance. However, you use it
>>> for hw tclass identification. This is mixing of apples and oranges.
>>>
>>> Why?
>>>
>>> Please don't try to abuse things! This is not nice.
>>
>>This isn't an abuse. This is reproducing in hardware what is already
>>the behavior for software. Isn't that how offloads are supposed to
>>work?
> 
> What is meaning of classid in HW? Classid is SW only identification of
> qdisc instances. No relation to HW instances = abuse.

Jiri I really don't see what the problem is.

As long as the driver does the right thing when changes are made to the
qdisc, it doesn't really matter what "key" they use to refer to it.

It could have just as easily used the qdisc pointer and then internally
use some IDR allocated ID to refer to it in the driver and hardware.

But that's such a waste, we have a unique handle already so why can't
the driver just use that?
Jiri Pirko Oct. 11, 2017, 8:58 p.m. | #6
Wed, Oct 11, 2017 at 10:46:52PM CEST, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Wed, 11 Oct 2017 22:38:32 +0200
>
>> Wed, Oct 11, 2017 at 07:46:27PM CEST, alexander.duyck@gmail.com wrote:
>>>On Wed, Oct 11, 2017 at 5:56 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>>> Wed, Oct 11, 2017 at 02:24:12AM CEST, amritha.nambiar@intel.com 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).
>>>>
>>>>
>>>> NACK. This clearly looks like abuse of classid to something
>>>> else. Classid is here to identify qdisc instance. However, you use it
>>>> for hw tclass identification. This is mixing of apples and oranges.
>>>>
>>>> Why?
>>>>
>>>> Please don't try to abuse things! This is not nice.
>>>
>>>This isn't an abuse. This is reproducing in hardware what is already
>>>the behavior for software. Isn't that how offloads are supposed to
>>>work?
>> 
>> What is meaning of classid in HW? Classid is SW only identification of
>> qdisc instances. No relation to HW instances = abuse.
>
>Jiri I really don't see what the problem is.
>
>As long as the driver does the right thing when changes are made to the
>qdisc, it doesn't really matter what "key" they use to refer to it.
>
>It could have just as easily used the qdisc pointer and then internally
>use some IDR allocated ID to refer to it in the driver and hardware.
>
>But that's such a waste, we have a unique handle already so why can't
>the driver just use that?

Well if I see classid, I expect it should refer to qdisc instance. So
far, this has been always a case. But for some drivers, this would mean
something totally different and unrelated. So what should I think?
What's next? Classid could be abused to identify something else. I don't
understand why.

classid in kernel and tclass in hw are 2 completely unrelated things.
Why they should share the same userspace api? What am I missing that
indicates this is not an abuse?

There should be clean and well-defined userspace api:
1) classid to identify qdisc instances
2) something else to identify HW tclasses
David Miller Oct. 11, 2017, 9:19 p.m. | #7
From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 11 Oct 2017 22:58:30 +0200

> Well if I see classid, I expect it should refer to qdisc instance. So
> far, this has been always a case. But for some drivers, this would mean
> something totally different and unrelated. So what should I think?
> What's next? Classid could be abused to identify something else. I don't
> understand why.
> 
> classid in kernel and tclass in hw are 2 completely unrelated things.

Why do they need to be different?

It's qdisc instance in both cases.  The driver is just using it to
refer to the qdisc as offloaded in the hardware.  It's a key, nothing
more.  The context in which it is used doesn't change it's meaning.

> Why they should share the same userspace api? What am I missing that
> indicates this is not an abuse?

Why invent a completely new ID space to refer to something we exactly
have an ID for already?

This duplication for the sake of "API" makes no sense to me.

The handle is not going away.  It is not going to stop referring to
a specific qdisc.

So it's stable and appropriate to use to refer to a qdisc, whatever
operation being performed, or offload being we are going to perform of
it.

I notice you are quite feisty lately in your reviews of other people's
work, so I have to ask if things are very stressful in your life?
Please drink a nice warm cup of tea and calm down :-)
Jiri Pirko Oct. 11, 2017, 9:28 p.m. | #8
Wed, Oct 11, 2017 at 11:19:29PM CEST, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Wed, 11 Oct 2017 22:58:30 +0200
>
>> Well if I see classid, I expect it should refer to qdisc instance. So
>> far, this has been always a case. But for some drivers, this would mean
>> something totally different and unrelated. So what should I think?
>> What's next? Classid could be abused to identify something else. I don't
>> understand why.
>> 
>> classid in kernel and tclass in hw are 2 completely unrelated things.
>
>Why do they need to be different?
>
>It's qdisc instance in both cases.  The driver is just using it to
>refer to the qdisc as offloaded in the hardware.  It's a key, nothing
>more.  The context in which it is used doesn't change it's meaning.
>
>> Why they should share the same userspace api? What am I missing that
>> indicates this is not an abuse?
>
>Why invent a completely new ID space to refer to something we exactly
>have an ID for already?
>
>This duplication for the sake of "API" makes no sense to me.
>
>The handle is not going away.  It is not going to stop referring to
>a specific qdisc.
>
>So it's stable and appropriate to use to refer to a qdisc, whatever
>operation being performed, or offload being we are going to perform of
>it.

Okay, fair enough. Yet, I can't say I'm happy with it :/ But I guess
that what you say makes sense.


>
>I notice you are quite feisty lately in your reviews of other people's
>work, so I have to ask if things are very stressful in your life?

:) Yeah, that is probably coincidental. Lots of odd offloading stuff is
happening lately.


>Please drink a nice warm cup of tea and calm down :-)

I'm perfectly calm. But thanks for showing the care :)
Nambiar, Amritha Oct. 11, 2017, 10:41 p.m. | #9
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
>
Alexander Duyck Oct. 12, 2017, 7:05 a.m. | #10
On Wed, Oct 11, 2017 at 1:58 PM, Jiri Pirko <jiri@resnulli.us> wrote:
> Wed, Oct 11, 2017 at 10:46:52PM CEST, davem@davemloft.net wrote:
>>From: Jiri Pirko <jiri@resnulli.us>
>>Date: Wed, 11 Oct 2017 22:38:32 +0200
>>
>>> Wed, Oct 11, 2017 at 07:46:27PM CEST, alexander.duyck@gmail.com wrote:
>>>>On Wed, Oct 11, 2017 at 5:56 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>>>> Wed, Oct 11, 2017 at 02:24:12AM CEST, amritha.nambiar@intel.com 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).
>>>>>
>>>>>
>>>>> NACK. This clearly looks like abuse of classid to something
>>>>> else. Classid is here to identify qdisc instance. However, you use it
>>>>> for hw tclass identification. This is mixing of apples and oranges.
>>>>>
>>>>> Why?
>>>>>
>>>>> Please don't try to abuse things! This is not nice.
>>>>
>>>>This isn't an abuse. This is reproducing in hardware what is already
>>>>the behavior for software. Isn't that how offloads are supposed to
>>>>work?
>>>
>>> What is meaning of classid in HW? Classid is SW only identification of
>>> qdisc instances. No relation to HW instances = abuse.
>>
>>Jiri I really don't see what the problem is.
>>
>>As long as the driver does the right thing when changes are made to the
>>qdisc, it doesn't really matter what "key" they use to refer to it.
>>
>>It could have just as easily used the qdisc pointer and then internally
>>use some IDR allocated ID to refer to it in the driver and hardware.
>>
>>But that's such a waste, we have a unique handle already so why can't
>>the driver just use that?
>
> Well if I see classid, I expect it should refer to qdisc instance. So
> far, this has been always a case. But for some drivers, this would mean
> something totally different and unrelated. So what should I think?
> What's next? Classid could be abused to identify something else. I don't
> understand why.

The general idea is we are trying to offload some of the qdisc work
down into the hardware. It is kind of hard to do that without
providing this sort of abstraction.

> classid in kernel and tclass in hw are 2 completely unrelated things.
> Why they should share the same userspace api? What am I missing that
> indicates this is not an abuse?

This is both true and not quite true. In the case of mqprio it is
already creating virtual qdiscs for each traffic class. That is
essentially what we are trying to emulate on the receive side. That
was why we thought we might use this abstraction.

> There should be clean and well-defined userspace api:
> 1) classid to identify qdisc instances
> 2) something else to identify HW tclasses

I agree with the well defined userspace api portion of this. However I
somewhat disagree on the HW tclasses argument as we have virtual
qdiscs floating around inside of mqprio for instance that represent
the same type of thing. You will find that the classid values with a
minor value less than or equal to the number of TCs don't actually
exist other than for collecting statistics. If that is all you are
looking for we could probably update ingress and clsact to at a
minimum display the class IDs and treat them as full virtual classids
within the qdisc. I figure it wouldn't make sense to add statistics
since they don't actually enqueue any packets.

One thought I am considering, is what if we change the class ID of the
virtual qdiscs for mqprio that represent priority based traffic
classes so that we reserved TC_H_MIN values 0xFFE0 - 0xFFEF to
represent traffic classes 0 through 15? The advantage would be that it
would make the classid layout for mqprio closer to what is already
there for mq, and then in addition we would have a block of values we
could use as reserved for mq, mqprio, ingress, and clsact to represent
what you refer to as the HW tclasses since mqprio is already doing
something like this.

- Alex
Jiri Pirko Oct. 12, 2017, 7:30 a.m. | #11
Thu, Oct 12, 2017 at 09:05:10AM CEST, alexander.duyck@gmail.com wrote:
>On Wed, Oct 11, 2017 at 1:58 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Wed, Oct 11, 2017 at 10:46:52PM CEST, davem@davemloft.net wrote:
>>>From: Jiri Pirko <jiri@resnulli.us>
>>>Date: Wed, 11 Oct 2017 22:38:32 +0200
>>>
>>>> Wed, Oct 11, 2017 at 07:46:27PM CEST, alexander.duyck@gmail.com wrote:
>>>>>On Wed, Oct 11, 2017 at 5:56 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>>>>> Wed, Oct 11, 2017 at 02:24:12AM CEST, amritha.nambiar@intel.com 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).
>>>>>>
>>>>>>
>>>>>> NACK. This clearly looks like abuse of classid to something
>>>>>> else. Classid is here to identify qdisc instance. However, you use it
>>>>>> for hw tclass identification. This is mixing of apples and oranges.
>>>>>>
>>>>>> Why?
>>>>>>
>>>>>> Please don't try to abuse things! This is not nice.
>>>>>
>>>>>This isn't an abuse. This is reproducing in hardware what is already
>>>>>the behavior for software. Isn't that how offloads are supposed to
>>>>>work?
>>>>
>>>> What is meaning of classid in HW? Classid is SW only identification of
>>>> qdisc instances. No relation to HW instances = abuse.
>>>
>>>Jiri I really don't see what the problem is.
>>>
>>>As long as the driver does the right thing when changes are made to the
>>>qdisc, it doesn't really matter what "key" they use to refer to it.
>>>
>>>It could have just as easily used the qdisc pointer and then internally
>>>use some IDR allocated ID to refer to it in the driver and hardware.
>>>
>>>But that's such a waste, we have a unique handle already so why can't
>>>the driver just use that?
>>
>> Well if I see classid, I expect it should refer to qdisc instance. So
>> far, this has been always a case. But for some drivers, this would mean
>> something totally different and unrelated. So what should I think?
>> What's next? Classid could be abused to identify something else. I don't
>> understand why.
>
>The general idea is we are trying to offload some of the qdisc work
>down into the hardware. It is kind of hard to do that without
>providing this sort of abstraction.

Well you expect classid being 0-7, to identify the tclass in hw.
What is I pass something else? I think that what DaveM suggests makes
sense. You should accept every classid and map it to 0-7 internally in
driver.


>
>> classid in kernel and tclass in hw are 2 completely unrelated things.
>> Why they should share the same userspace api? What am I missing that
>> indicates this is not an abuse?
>
>This is both true and not quite true. In the case of mqprio it is
>already creating virtual qdiscs for each traffic class. That is
>essentially what we are trying to emulate on the receive side. That
>was why we thought we might use this abstraction.
>
>> There should be clean and well-defined userspace api:
>> 1) classid to identify qdisc instances
>> 2) something else to identify HW tclasses
>
>I agree with the well defined userspace api portion of this. However I
>somewhat disagree on the HW tclasses argument as we have virtual
>qdiscs floating around inside of mqprio for instance that represent
>the same type of thing. You will find that the classid values with a
>minor value less than or equal to the number of TCs don't actually
>exist other than for collecting statistics. If that is all you are
>looking for we could probably update ingress and clsact to at a
>minimum display the class IDs and treat them as full virtual classids
>within the qdisc. I figure it wouldn't make sense to add statistics

Agreed. I'm not happy how clsact ingress/egress classids are
implemented. The virtual qdiscs you are suggesting make sense.


>since they don't actually enqueue any packets.
>
>One thought I am considering, is what if we change the class ID of the
>virtual qdiscs for mqprio that represent priority based traffic
>classes so that we reserved TC_H_MIN values 0xFFE0 - 0xFFEF to
>represent traffic classes 0 through 15? The advantage would be that it
>would make the classid layout for mqprio closer to what is already
>there for mq, and then in addition we would have a block of values we
>could use as reserved for mq, mqprio, ingress, and clsact to represent
>what you refer to as the HW tclasses since mqprio is already doing
>something like this.
>
>- Alex