From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Nambiar, Amritha" <amritha.nambiar@intel.com>
Subject: Re: [iproute2-next PATCH v4] tc: flower: Classify packets based port
 ranges
Date: Tue, 27 Nov 2018 13:47:55 -0800
Message-ID: <730a79de-1b43-9ba8-4b9b-df26b4875651@intel.com>
References: <154278102460.66868.7581842092203300039.stgit@anamhost.jf.intel.com>
 <4b11cf66-089d-1a13-fae9-d471de9064ea@gmail.com>
 <0bce82ec-4f3c-2a56-7d57-f89005ed766c@intel.com>
 <b6f120b8-b864-654c-6bfe-583932b024cf@gmail.com>
 <5ff60af4-ddc9-848a-234d-6ca43f22af18@intel.com>
 <20181126200254.0a213bbd@xeon-e3>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Cc: David Ahern <dsahern@gmail.com>, netdev@vger.kernel.org,
        jakub.kicinski@netronome.com, sridhar.samudrala@intel.com,
        jhs@mojatatu.com, xiyou.wangcong@gmail.com, jiri@resnulli.us
To: Stephen Hemminger <stephen@networkplumber.org>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mga04.intel.com ([192.55.52.120]:8091 "EHLO mga04.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1726288AbeK1IrP (ORCPT <rfc822;netdev@vger.kernel.org>);
        Wed, 28 Nov 2018 03:47:15 -0500
In-Reply-To: <20181126200254.0a213bbd@xeon-e3>
Content-Language: en-US
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On 11/26/2018 8:02 PM, Stephen Hemminger wrote:
> On Mon, 26 Nov 2018 17:56:10 -0800
> "Nambiar, Amritha" <amritha.nambiar@intel.com> wrote:
> 
>> On 11/26/2018 4:43 PM, David Ahern wrote:
>>> On 11/26/18 5:23 PM, Nambiar, Amritha wrote:  
>>>>> Can tc flower use something similar to ip ru with single port or port
>>>>> range handled like this?
>>>>>
>>>>>     },{
>>>>>         "priority": 32764,
>>>>>         "src": "172.16.1.0",
>>>>>         "srclen": 24,
>>>>>         "ipproto": "tcp",
>>>>>         "sport": 1100,
>>>>>         "table": "main"
>>>>>     },{
>>>>>         "priority": 32765,
>>>>>         "src": "172.16.1.0",
>>>>>         "srclen": 24,
>>>>>         "ipproto": "tcp",
>>>>>         "sport_start": 1000,
>>>>>         "sport_end": 1010,
>>>>>         "table": "main"
>>>>>     },{
>>>>>
>>>>>  
>>>>
>>>> Does it have to be separate fields "sport_start" and "sport_end"?
>>>> Removing the space and 'range' keyword will make the output format
>>>> consistent with the input format and print as "sport <number>" for
>>>> single port and "sport <start>-<end>" for range.
>>>> Example:
>>>>
>>>> ... flower ip_proto tcp src_port 12 skip_hw action will print as:
>>>>   ip_proto tcp
>>>>   src_port 12
>>>>   skip_hw
>>>>   not_in_hw
>>>>         action
>>>>
>>>> ... flower ip_proto tcp src_port 100-200 skip_hw action :
>>>>   ip_proto tcp
>>>>   src_port 100-200
>>>>   skip_hw
>>>>   not_in_hw
>>>>         action  
>>>
>>> non-json output needs to match what the user gives on the command line.
>>>
>>> My comment was about consistency with json output when possible. I am
>>> not a json expert by any means. Other commands have a single key value
>>> pair, so I suspect the json here needs to follow suit (ie., not
>>> "src_port": "1000-1010" but separate start and end entries).
>>>   
>> I'm not quite familiar with json. Maybe, Jiri can give feedback here.
> 
> JSON support strings and numeric and objects.
> The more common JSON way of expressing this would be either as object for sport
> 
> {
>        "priority": 32765,
>        "src": "172.16.1.0",
>         "srclen": 24,
>        "ipproto": "tcp",
> 	"sport" : {
> 		"start" : 1000,
> 		"end" : 1010
> 	},
> 	"table: "main"
> }
> 
> or as an array:
> {
>        "priority": 32765,
>        "src": "172.16.1.0",
>         "srclen": 24,
>        "ipproto": "tcp",
> 	"sport" : [ 1000, 1010 ],
> 	"table: "main"
> }
> 
> My point is don't build some semantic meaning directly into the tag part of the syntax.
> 

Okay. Will fix this in v6. I'll keep the default (non-json) output
format similar to the input format, and for the json output, I'll use
the object for sport as in the first example above.