From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Subject: Re: [RFC net-next v1 1/1] net/sched: Introduce the taprio scheduler
Date: Mon, 16 Jul 2018 14:06:20 -0700
Message-ID: <20180716140620.4c171c6d@cakuba.lan>
References: <20180714000536.1008-1-vinicius.gomes@intel.com>
        <20180714000536.1008-2-vinicius.gomes@intel.com>
        <20180714064505.GA2821@nanopsycho.orion>
        <87va9fgl3g.fsf@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Jiri Pirko <jiri@resnulli.us>, netdev@vger.kernel.org,
        jesus.sanchez-palencia@intel.com, tglx@linutronix.de,
        jan.altenberg@linutronix.de, henrik@austad.us,
        richardcochran@gmail.com, levi.pearson@harman.com,
        jhs@mojatatu.com, xiyou.wangcong@gmail.com
To: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-qt0-f177.google.com ([209.85.216.177]:34720 "EHLO
        mail-qt0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1728639AbeGPVff (ORCPT
        <rfc822;netdev@vger.kernel.org>); Mon, 16 Jul 2018 17:35:35 -0400
Received: by mail-qt0-f177.google.com with SMTP id m13-v6so34181567qth.1
        for <netdev@vger.kernel.org>; Mon, 16 Jul 2018 14:06:25 -0700 (PDT)
In-Reply-To: <87va9fgl3g.fsf@intel.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Mon, 16 Jul 2018 10:13:23 -0700, Vinicius Costa Gomes wrote:
> Hi Jiri,
> 
> Jiri Pirko <jiri@resnulli.us> writes:
> 
> [...]
> 
> >>
> >>gates.sched  
> >
> > Any particular reason this has to be in file and not on the cmdline?  
> 
> The idea here was to keep longer schedules more manageable. And during
> testing I found it more ergonomic to have a file.
> 
> It also has the advantage that the file can be reused by other tools,
> dump-classifier (awful name, I admit), included in that github gist, is
> one example, it uses the schedule (and some more information) to
> calculate which packets would fall outside their "windows" in a pcap
> dump.
> 
> Anyway, if there are use cases that having the schedule in the command
> line helps, I would be happy to add it.

FWIW there is some precedent in cls_bpf/act_bpf for allowing specifying
potentially long sequences both in command line and as a file (cBPF
filters in that case - see man tc-bpf bytecode and bytecode-file).