[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2438e8ee-99ad-167d-d00c-fc208ba7caa9@gmail.com>
Date: Wed, 16 Dec 2020 23:12:12 +0000
From: Edward Cree <ecree.xilinx@...il.com>
To: Jesper Dangaard Brouer <brouer@...hat.com>
Cc: Ivan Babrou <ivan@...udflare.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, bpf@...r.kernel.org,
kernel-team@...udflare.com,
Martin Habets <habetsm.xilinx@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Jesper Dangaard Brouer <hawk@...nel.org>,
John Fastabend <john.fastabend@...il.com>,
Marek Majtyka <marekx.majtyka@...el.com>
Subject: Re: [PATCH net-next] sfc: reduce the number of requested xdp ev
queues
On 16/12/2020 08:45, Jesper Dangaard Brouer wrote:
> So, what I hear is that this fix is just pampering over the real issue.
Yes, it is, but it's better than nothing in the meantime while we work
out the complete fix.
> I suggest that you/we detect the situation, and have a code path that
> will take a lock (per 16 packets bulk) and solve the issue.
Imho that would _also_ paper over the issue, because it would mean the
system degraded to a lower performance mode of operation, while still
appearing to support XDP_TX. I think that that in general should not
happen unless there is a way for the user to determine at runtime
whether it has/should happen. Perhaps Marek's new XDP feature flags
could include a "tx-lockless" flag to indicate this?
-ed
Powered by blists - more mailing lists