[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160601215947.23820510@jkicinski-Precision-T1700>
Date: Wed, 1 Jun 2016 21:59:47 +0100
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
To: John Fastabend <john.fastabend@...il.com>
Cc: netdev@...r.kernel.org, ast@...nel.org, daniel@...earbox.net,
dinan.gunawardena@...ronome.com
Subject: Re: [RFC 02/12] net: cls_bpf: add hardware offload
On Wed, 1 Jun 2016 10:13:48 -0700, John Fastabend wrote:
> > +static void cls_bpf_stop_offload(struct tcf_proto *tp,
> > + struct cls_bpf_prog *prog)
> > +{
> > + struct net_device *dev = tp->q->dev_queue->dev;
> > +
> > + if (!prog->offloaded)
> > + return;
> > + if (WARN_ON(!tc_should_offload(dev, 0)))
> > + return;
>
> This warn on is a bit concerning it looks like you can get
> a program stuck in hardware but removed from the software
> stack. Any idea why this could happen? I think it is better
> to solve the root problem or just remove this if its dbg code.
>
> One thought is you need to block disabling the ethtool flag
> if the hardware has running ebpf codes. Haven't got to the
> driver patches yet though so not sure if you did this or not.
> And now that I think about it I better go check the other
> drivers.
Yes, I do refuse clearing the ethtool flag if offload is active.
I put the warning there in an attempt to document that "this should
never happen". I'll drop it in the next revision.
Powered by blists - more mailing lists