From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Subject: Re: [PATCH net-next v2 3/4] net: check tunnel option type in tunnel
 flags
Date: Thu, 28 Jun 2018 10:05:36 -0700
Message-ID: <20180628100536.71e5ca59@cakuba.netronome.com>
References: <20180627043937.25431-1-jakub.kicinski@netronome.com>
        <20180627043937.25431-4-jakub.kicinski@netronome.com>
        <c426f1d5-e317-0564-d2f7-3bb8662479c7@iogearbox.net>
        <20180628094206.62b6d8e2@redhat.com>
        <20180628095452.6f23fdf4@cakuba.netronome.com>
        <20180628190152.539bfc67@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Daniel Borkmann <daniel@iogearbox.net>, davem@davemloft.net,
        Roopa Prabhu <roopa@cumulusnetworks.com>, jiri@resnulli.us,
        jhs@mojatatu.com, xiyou.wangcong@gmail.com,
        oss-drivers@netronome.com, netdev@vger.kernel.org,
        Pieter Jansen van Vuuren
        <pieter.jansenvanvuuren@netronome.com>
To: Jiri Benc <jbenc@redhat.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-qt0-f195.google.com ([209.85.216.195]:45019 "EHLO
        mail-qt0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S965095AbeF1RFl (ORCPT
        <rfc822;netdev@vger.kernel.org>); Thu, 28 Jun 2018 13:05:41 -0400
Received: by mail-qt0-f195.google.com with SMTP id 92-v6so5365966qta.11
        for <netdev@vger.kernel.org>; Thu, 28 Jun 2018 10:05:41 -0700 (PDT)
In-Reply-To: <20180628190152.539bfc67@redhat.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Thu, 28 Jun 2018 19:01:52 +0200, Jiri Benc wrote:
> On Thu, 28 Jun 2018 09:54:52 -0700, Jakub Kicinski wrote:
> > Hmm... in practice we could steal top bits of the size parameter for
> > some flags, since it seems to be limited to values < 256 today?  Is it
> > worth it?
> > 
> > It would look something along the lines of:  
> 
> Something like that, yes. I'll leave to Daniel to review how much sense
> it makes from the BPF side.

Can we take this as a follow up through the bpf-next tree or do you
want us to respin as part of this set?