From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Subject: Re: [patch net-next v3 05/10] net: sched: keep track of offloaded
 filters and check tc offload feature
Date: Thu, 14 Dec 2017 10:49:41 -0800
Message-ID: <20171214104941.2f051af1@cakuba.netronome.com>
References: <20171213151038.29665-1-jiri@resnulli.us>
        <20171213151038.29665-6-jiri@resnulli.us>
        <20171213170555.2a1e3022@cakuba.netronome.com>
        <20171214094716.GA1926@nanopsycho>
        <20171214131045.GD1926@nanopsycho>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: netdev@vger.kernel.org, davem@davemloft.net, jhs@mojatatu.com,
        xiyou.wangcong@gmail.com, mlxsw@mellanox.com, andrew@lunn.ch,
        vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com,
        michael.chan@broadcom.com, ganeshgr@chelsio.com,
        saeedm@mellanox.com, matanb@mellanox.com, leonro@mellanox.com,
        idosch@mellanox.com, simon.horman@netronome.com,
        pieter.jansenvanvuuren@netronome.com, john.hurley@netronome.com,
        alexander.h.duyck@intel.com, ogerlitz@mellanox.com,
        john.fastabend@gmail.com, daniel@iogearbox.net
To: Jiri Pirko <jiri@resnulli.us>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-qk0-f194.google.com ([209.85.220.194]:39097 "EHLO
        mail-qk0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1753742AbdLNStr (ORCPT
        <rfc822;netdev@vger.kernel.org>); Thu, 14 Dec 2017 13:49:47 -0500
Received: by mail-qk0-f194.google.com with SMTP id u184so7474200qkd.6
        for <netdev@vger.kernel.org>; Thu, 14 Dec 2017 10:49:46 -0800 (PST)
In-Reply-To: <20171214131045.GD1926@nanopsycho>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Thu, 14 Dec 2017 14:10:45 +0100, Jiri Pirko wrote:
> >Why? Just a namechange?
> >
> >  
> >>IIUC the problem is we don't know whether the driver/callee of the new
> >>port is aware of previous callbacks/filters and we can't replay them.  
> 
> Well, the problem is a bit different.
> There are 2 scenarios when we need to fail here:
> 1) tc offload feature is turned off, there are some filters offloaded in
>    the block. That is what I commented above.
> 2) tc offload feature is turned on, there are some filters offloaded in
>    the block but the block is not accounted by the driver. This is
>    because of the lack or replay. This is taken care of in the beginning
>    of __tcf_block_cb_register function - see below, there is a comment
>    there.

Restating in code terms, shouldn't this:

+	tcf_block_offload_cmd(block, dev, ei, TC_BLOCK_BIND);
+	return 0;

return the error like this:

	return tcf_block_offload_cmd(block, dev, ei, TC_BLOCK_BIND);

We expect simple drivers to do this:

	case TC_BLOCK_BIND:
		return tcf_block_cb_register(f->block, mycb,
					     priv, priv);

Which will return an error for shared offloaded block, just need to
propagate it.