FC tags
Changed in v2:
* use array instead of new callback for getting stats
* remove CVLAN patch (posted separately for net)
* add header inclusion fix
Edward Cree (3):
flow_offload: add a cookie to flow_action_entry
flow_offload: restore ability to collect separate stats per action
flow_o
flow_stats_update() uses max_t, so ensure we have that defined.
Signed-off-by: Edward Cree
---
include/net/flow_offload.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/net/flow_offload.h b/include/net/flow_offload.h
index ae7cf27cd5e3..7554e88581d2 100644
--- a/include/net
Populated with the address of the struct tc_action from which it was made.
Required for support of shared counters (and possibly other shared per-
action entities in future).
Signed-off-by: Edward Cree
---
include/net/flow_offload.h | 1 +
net/sched/cls_api.c| 1 +
2 files changed, 2
ats_update()).
Also do the same in mall_stats_hw_filter()'s TC_CLSMATCHALL_STATS
callback, since it also uses tcf_exts_stats_update().
Signed-off-by: Edward Cree
---
drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c | 6 --
.../net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c | 10 ++--
On 22/05/2019 23:20, Jakub Kicinski wrote:
> On Wed, 22 May 2019 22:37:16 +0100, Edward Cree wrote:
>> * removed RFC tags
> Why? There is still no upstream user for this
Well, patch #2 updates drivers to the changed API, which is kinda an
"upstream user" if you squint... ad
On 23/05/2019 17:11, Jakub Kicinski wrote:
> On Thu, 23 May 2019 09:19:49 -0400, Jamal Hadi Salim wrote:
>> That would still work here, no? There will be some latency
>> based on the frequency of hardware->kernel stats updates.
> I don't think so, I think the stats are only updated on classifier
>
On 23/05/2019 17:33, Jakub Kicinski wrote:
> On Thu, 23 May 2019 17:21:49 +0100, Edward Cree wrote:
>> Well, patch #2 updates drivers to the changed API, which is kinda an
>> "upstream user" if you squint... admittedly patch #1 is a bit dubious
>> in that regard
On 23/05/2019 18:25, Jakub Kicinski wrote:
> Whether it's on you to fix this is debatable :) Since you're diving
> into actions and adding support for shared ones, I'd say it's time to
> rectify the situation.
>
> Let's look at it this way - if you fix the RTM_GETACTION you will
> necessarily add t
On 24/05/2019 14:09, Edward Cree wrote:
> I'll put together an RFC patch, anyway
Argh, there's a problem: an action doesn't have a (directly) associated
block, and all the TC offload machinery nowadays is built around blocks.
Since this action might have been used in _any
On 24/05/2019 15:44, Jamal Hadi Salim wrote:
> On 2019-05-24 9:57 a.m., Edward Cree wrote:
>> Argh, there's a problem: an action doesn't have a (directly) associated
>> block, and all the TC offload machinery nowadays is built around blocks.
>> Since this actio
On 24/05/2019 18:03, Jakub Kicinski wrote:
> On Fri, 24 May 2019 14:57:24 +0100, Edward Cree wrote:
>> Argh, there's a problem: an action doesn't have a (directly) associated
>> block, and all the TC offload machinery nowadays is built around blocks.
>> Since this
On 24/05/2019 18:44, Jakub Kicinski wrote:
> On Fri, 24 May 2019 18:27:39 +0100, Edward Cree wrote:
>> On 24/05/2019 18:03, Jakub Kicinski wrote:
>>> Simplest would be to keep a list of offloaders per action, but maybe
>>> something more clever would appear as on
d drivers could choose to implement one or the other (but not both). And
of course we could elide the calls when a->ops->stats_update == NULL.
Maybe that's a crazy idea, I don't know.
Edward Cree (2):
net/sched: add callback to get stats on an action from clsflower
offload
.
Signed-off-by: Edward Cree
---
include/linux/netdevice.h | 1 +
include/net/act_api.h | 2 +-
include/net/pkt_cls.h | 18 ++
net/sched/act_api.c | 51 +++
net/sched/cls_flower.c| 7 ++
5 files changed, 78 insertions(+), 1
cls_matchall, cls_u32, and cls_bpf all have offloads as well, so they also
need to bind actions to blocks for RTM_GETACTION stats collection.
Signed-off-by: Edward Cree
---
net/sched/cls_bpf.c | 10 +-
net/sched/cls_matchall.c | 7 +++
net/sched/cls_u32.c | 7 +++
3
flow_stats_update() uses max_t, so ensure we have that defined.
Signed-off-by: Edward Cree
---
include/net/flow_offload.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/net/flow_offload.h b/include/net/flow_offload.h
index ae7cf27cd5e3..7554e88581d2 100644
--- a/include/net
wrap the list_func invocation.
>
> Fixes: 92884ca8830b ("net: fix indirect calls helpers for ptype list hooks.")
> Suggested-by: Eric Dumazet
> Signed-off-by: Paolo Abeni
Acked-by: Edward Cree
s
* removed RFC tags
Changed in v2:
* use array instead of new callback for getting stats
* remove CVLAN patch (posted separately for net)
* add header inclusion fix
Edward Cree (4):
flow_offload: add a cookie to flow_action_entry
net/sched: add callback to get stats on an action from clsflo
Populated with the address of the struct tc_action from which it was made.
Required for support of shared counters (and possibly other shared per-
action entities in future).
Signed-off-by: Edward Cree
---
include/net/flow_offload.h | 1 +
net/sched/cls_api.c| 1 +
2 files changed, 2
.
Signed-off-by: Edward Cree
---
include/linux/netdevice.h | 1 +
include/net/act_api.h | 2 +-
include/net/pkt_cls.h | 18 ++
net/sched/act_api.c | 50 +++
net/sched/cls_flower.c| 7 ++
5 files changed, 77 insertions(+), 1
cls_matchall, cls_u32, and cls_bpf all have offloads as well, so they also
need to bind actions to blocks for RTM_GETACTION stats collection.
Signed-off-by: Edward Cree
---
net/sched/cls_bpf.c | 10 +-
net/sched/cls_matchall.c | 7 +++
net/sched/cls_u32.c | 7 +++
3
Drivers that support per-action stats should implement TC_ACTION_STATS
rather than TC_CLSFLOWER_STATS/TC_CLSMATCHALL_STATS.
Signed-off-by: Edward Cree
---
include/net/act_api.h | 5 +
include/net/flow_offload.h | 1 +
net/sched/act_api.c| 3 ++-
net/sched/cls_api.c| 1
On 07/06/2019 19:55, Tom Herbert wrote:
> This patch set includes fixes to bring the segment routing
> implementation into conformance with the latest version of the
> draft (draft-ietf-6man-segment-routing-header-19).
AIUI the concept of "conformance" doesn't really belong in the context
of an In
On 10/06/2019 15:03, Tom Herbert wrote:
> On Mon, Jun 10, 2019, 5:54 AM Edward Cree <mailto:ec...@solarflare.com>> wrote:
>
> On 07/06/2019 19:55, Tom Herbert wrote:
> > This patch set includes fixes to bring the segment routing
> > implementation in
On 12/07/2019 17:48, Eric Dumazet wrote:
>> but the rest is the stuff we're polling for for low latency.
>> I'm putting a gro_normal_list() call after the trace_napi_poll() in
>> napi_busy_loop() and testing that, let's see how it goes...
One thing that's causing me some uncertainty: busy_poll_sto
On 24/07/2019 22:49, Edward Cree wrote:
> One thing that's causing me some uncertainty: busy_poll_stop() does a
> napi->poll(), which can potentially gro_normal_one() something. But
> when I tried to put a gro_normal_list() just after that, I ran into
> list corruption b
the napi busy loop. See comments in Patch #3 for
complications of doing the same in busy_poll_stop().
[1]: Cohen 1959, doi: 10.1080/00401706.1959.10489859
Edward Cree (3):
sfc: don't score irq moderation points for GRO
sfc: falcon: don't score irq moderation points for GRO
net:
testing with four TCP streams received on a single CPU (where
throughput was line rate of 9.4Gbps in all tests) showed a 13.7% reduction
in RX CPU usage (n=6, p=0.03).
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/rx.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff
Same rationale as for sfc, except that this wasn't performance-tested.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/falcon/rx.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/sfc/falcon/rx.c
b/drivers/net/ethernet/sfc/falcon/rx.c
s an inefficiently large batch, also consume the
list whenever it exceeds gro_normal_batch, a new net/core sysctl that
defaults to 8.
Signed-off-by: Edward Cree
---
include/linux/netdevice.h | 3 +++
net/core/dev.c | 44 +++---
net/core/sysc
mments after a week means no-one objects, right?)
Changed in v2:
* During busy poll, call gro_normal_list() to receive batched packets
after each cycle of the napi busy loop. See comments in Patch #3 for
complications of doing the same in busy_poll_stop().
[1]: Cohen 1959, doi: 10.1080/004017
Same rationale as for sfc, except that this wasn't performance-tested.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/falcon/rx.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/sfc/falcon/rx.c
b/drivers/net/ethernet/sfc/falcon/rx.c
testing with four TCP streams received on a single CPU (where
throughput was line rate of 9.4Gbps in all tests) showed a 13.7% reduction
in RX CPU usage (n=6, p=0.03).
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/rx.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff
s an inefficiently large batch, also consume the
list whenever it exceeds gro_normal_batch, a new net/core sysctl that
defaults to 8.
Signed-off-by: Edward Cree
---
include/linux/netdevice.h | 3 +++
net/core/dev.c | 44 +++---
net/core/sysc
On 09/08/2019 18:14, Ioana Ciocoi Radulescu wrote:
> Hi Edward,
>
> I'm probably missing a lot of context here, but is there a reason
> this change targets only the napi_gro_frags() path and not the
> napi_gro_receive() one?
> I'm trying to understand what drivers that don't call napi_gro_frags()
>
On 09/07/2019 21:55, Pablo Neira Ayuso wrote:
> This patch updates flow_block_cb_setup_simple() to use the flow block API.
> Several drivers are also adjusted to use it.
>
> This patch introduces the per-driver list of flow blocks to account for
> blocks that are already in use.
>
> Remove tc_block
other channels, max 32)
>
> Which in turn triggers EINVAL on XDP processing:
>
> sfc :86:00.0 ext0: XDP TX failed (-22)
>
> Signed-off-by: Ivan Babrou
Acked-by: Edward Cree
On 21/01/2021 13:04, Mark Pashmfouroush wrote:
> My question is, what can cause a fragmented/non-linear UDP skb to be>
> allocated by the sfc driver, and why has this frequency increased since
> transitioning to the in-tree driver?
By default sfc doesn't RX things as linear; we get one or more RX
comes from the driver's channel structures having been designed a
decade ago when 32 cpus ought to be enough for anybody... AFAIR the
hardware is capable of giving us something like 1024 evqs if we ask
for them, it just might not have that many msi-x vectors for us.)
Anyway, the patch looks correct, so
Acked-by: Edward Cree
-ed
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
On 27/11/2020 19:37, t...@redhat.com wrote:
> From: Tom Rix
>
> The macro use will already have a semicolon.
>
> Signed-off-by: Tom Rix
> ---
> net/core/flow_offload.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/core/flow_offload.c b/net/core/flow_offload.c
>
On 03/12/2020 19:52, John Ousterhout wrote:
> Homa uses GRO to collect batches of packets for protocol processing,
> but there are times when it wants to push a batch of packet up through
> the stack immediately (it doesn't want any more packets to be
> processed at NAPI level before pushing the ba
On 07/12/2020 20:10, Jakub Kicinski wrote:
> On Mon, 7 Dec 2020 11:35:53 -0800 Brian Norris wrote:
>> Is there some reference for this rule (e.g., dictate from on high; or
>> some explanation of reasons)? Or limitations on it?
>
> TBH its one of those "widely accepted truth" in networking which wa
On 25/11/2020 00:32, Miguel Ojeda wrote:
> I have said *authoring* lines of *this* kind takes a minute per line.
> Specifically: lines fixing the fallthrough warning mechanically and
> repeatedly where the compiler tells you to, and doing so full-time for
> a month.
> It is useful since it makes i
On 24/11/2020 21:25, Kees Cook wrote:
> I still think this isn't right -- it's a case statement that runs off
> the end without an explicit flow control determination.
Proves too much — for instance
case foo:
case bar:
thing;
break;
doesn't require a fallthrough; after cas
On 05/11/2020 14:05, Jamal Hadi Salim wrote:
> On 2020-11-04 10:19 p.m., David Ahern wrote:
>
> [..]
>> Similarly, it is not realistic or user friendly to *require* general
>> Linux users to constantly chase latest versions of llvm, clang, dwarves,
>> bcc, bpftool, libbpf, (I am sure I am missing m
On 11/11/2020 00:53, Alexei Starovoitov wrote:
> On Tue, Nov 10, 2020 at 12:47:28PM +0000, Edward Cree wrote:
>> But I think it illustrates why having to
>> interoperate with systems outside their control and mix-and-match
>> versioning of various components provides ext
This series adds support for GRE and GRE_CSUM TSO on EF100 NICs, as
well as improving the handling of UDP tunnel TSO.
Edward Cree (3):
sfc: extend bitfield macros to 19 fields
sfc: correctly support non-partial GSO_UDP_TUNNEL_CSUM on EF100
sfc: support GRE TSO on EF100
drivers/net
By asking the HW for the correct edits, we can make UDP tunnel TSO
work without needing GSO_PARTIAL. So don't specify it in our
netdev->gso_partial_features.
However, retain GSO_PARTIAL support, as this will be used for other
protocols later.
Signed-off-by: Edward Cree
---
dri
Our TSO descriptors got even more fussy.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/bitfield.h | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/sfc/bitfield.h
b/drivers/net/ethernet/sfc/bitfield.h
index
We can treat SKB_GSO_GRE almost exactly the same as UDP tunnels, except
that we don't want to edit the outer UDP len (as there isn't one).
For SKB_GSO_GRE_CSUM, we have to use GSO_PARTIAL as the device doesn't
support offload of non-UDP outer L4 checksums.
Signed-off-
On 13/11/2020 19:06, Alexander Duyck wrote:
> On Thu, Nov 12, 2020 at 7:23 AM Edward Cree wrote:
>> @@ -348,7 +352,11 @@ typedef union efx_oword {
>> #endif
>>
>> /* Populate an octword field with various numbers of arguments */
>> -#define EFX_POPULATE_OWORD_
On 17/11/2020 02:37, Alexei Starovoitov wrote:
> If a company built a bpf-based product and wants to distibute such
> product as a package it needs a way to specify this dependency in pkg config.
> 'tc -V' is not something that can be put in a spec.
> The main iproute2 version can be used as a depe
with metadata, we can safely remove
> GRO_DROP since it offers no practical use.
>
> Signed-off-by: Eric Dumazet
> Cc: Jesse Brandeburg
Fwiw,
Acked-by: Edward Cree
Without wishing to weigh in on whether this caching is a good idea...
Wouldn't it be simpler, rather than having two separate "alloc" and "flush"
caches, to have a single larger cache, such that whenever it becomes full
we bulk flush the top half, and when it's empty we bulk alloc the bottom
hal
efx_probe_filters() has not been called yet when EF100 calls into
efx_mcdi_filter_table_probe(), for which it wants to take the
filter_sem.
Fixes: a9dc3d5612ce ("sfc_ef100: RX filter table management and related
gubbins")
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef
On 26/10/2020 23:47, Sasha Levin wrote:
> From: Edward Cree
>
> [ Upstream commit 1c0544d24927e4fad04f858216b8ea767a3bd123 ]
>
> Instead of using efx_tx_queue_partner(), which relies on the assumption
> that tx_queues_per_channel is 2, efx_tx_send_pending() iterates
but when I tested
TSO over both underlay and (VxLAN) overlay, the checksums came
out correctly, so at least in those cases the edits we're making
must be the right ones.
Similarly, I'm not 100% sure I've correctly understood how FIXEDID
and MANGLEID are supposed to work in patch #3
We need EFX_POPULATE_OWORD_17 for an encap TSO descriptor on EF100.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/bitfield.h | 42 +
1 file changed, 37 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/sfc/bitfield.h
b/drivers/net/ethernet
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef100_nic.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/sfc/ef100_nic.c
b/drivers/net/ethernet/sfc/ef100_nic.c
index 8a187a16ac89..cd93c5ffd45c 100644
--- a/drivers/net/ethernet/sfc/ef100_nic.c
+++ b/drivers
a per-skb basis, rather than using
the MANGLEID feature to make all TSOs fixed-id.
Includes other minor cleanups of ef100_make_tso_desc() coding style.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef100_nic.c | 2 +-
drivers/net/ethernet/sfc/ef100_tx.c | 13 +++--
2 files
clear to me whether the stack will ever use the non-PARTIAL
version with the netdev feature flags we're setting here.)
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef100_nic.c | 13 ++--
drivers/net/ethernet/sfc/ef100_tx.c | 45
2 files c
On 30/10/2020 15:49, Willem de Bruijn wrote:
> On Wed, Oct 28, 2020 at 9:39 PM Edward Cree wrote:
>> + ESF_GZ_TX_TSO_ED_OUTER_UDP_LEN, encap &&
>> !gso_partial,
>
> This is a boolean field to signal whether the NIC needs to fix up
On 30/10/2020 16:26, Willem de Bruijn wrote:
> Then you could (as follow-up) advertise without GSO_PARTIAL and avoid
> the whole transition through the gso layer?
The thing is, non-PARTIAL offload only supports tunnels that the NIC
understands (single-layer UDP tunnels), but AIUI GSO_PARTIAL can
On 30/10/2020 17:33, Willem de Bruijn wrote:
> On Fri, Oct 30, 2020 at 12:43 PM Edward Cree wrote:
>> But possibly I don't need to have NETIF_F_GSO_UDP_TUNNEL[_CSUM] in
>> net_dev->gso_partial_features?
> If the device can handle fixing the odd last segment length
On 04/11/2020 03:11, Alexei Starovoitov wrote:
> The user will do 'tc -V'. Does version mean anything from bpf loading pov?
> It's not. The user will do "ldd `which tc`" and then what?
Is it beyond the wit of man for 'tc -V' to output somethingabout
libbpf version?
Other libraries seem to solve th
On 04/11/2020 22:10, Alexei Starovoitov wrote:
> On Wed, Nov 4, 2020 at 1:16 PM Edward Cree wrote:
>> On 04/11/2020 03:11, Alexei Starovoitov wrote:
>>> The user will do 'tc -V'. Does version mean anything from bpf loading pov?
>>> It's not. The user wil
On 14/04/2021 04:44, Jakub Kicinski wrote:
> Report what appears to be the standard block counts:
> - 30.5.1.1.17 aFECCorrectedBlocks
> - 30.5.1.1.18 aFECUncorrectableBlocks
>
> Don't report the per-lane symbol counts, if those really
> count symbols they are not what the standard calls for
> (e
and also a similarly incorrect code-path on
EF10 which worked by chance.
Edward Cree (3):
sfc: farch: fix TX queue lookup in TX flush done handling
sfc: farch: fix TX queue lookup in TX event handling
sfc: ef10: fix TX queue lookup in TX event handling
drivers/net/ethernet/sfc/ef10.c | 3 +-
We're starting from a TXQ instance number ('qid'), not a TXQ type, so
efx_get_tx_queue() is inappropriate (and could return NULL, leading
to panics).
Fixes: 12804793b17c ("sfc: decouple TXQ type from label")
Reported-by: Trevor Hemsley
Cc: sta...@vger.kernel.org
S
We're starting from a TXQ label, not a TXQ type, so
efx_channel_get_tx_queue() is inappropriate (and could return NULL,
leading to panics).
Fixes: 12804793b17c ("sfc: decouple TXQ type from label")
Cc: sta...@vger.kernel.org
Signed-off-by: Edward Cree
---
drivers/net/ethernet/
We're starting from a TXQ label, not a TXQ type, so
efx_channel_get_tx_queue() is inappropriate. This worked by chance,
because labels and types currently match on EF10, but we shouldn't
rely on that.
Fixes: 12804793b17c ("sfc: decouple TXQ type from label")
Signed
On 15/04/2021 23:53, Jakub Kicinski wrote:
> Report what appears to be the standard block counts:
> - 30.5.1.1.17 aFECCorrectedBlocks
> - 30.5.1.1.18 aFECUncorrectableBlocks
>
> Don't report the per-lane symbol counts, if those really
> count symbols they are not what the standard calls for
> (e
struct xdp_frame **xdpfs,
> if (flush && i > 0)
> efx_nic_push_buffers(tx_queue);
>
> - if (i == 0)
> - return -EIO;
> -
> - efx_xdp_return_frames(n - i, xdpfs + i);
> -
> - return i;
> + return i == 0 ? -EIO : i
On 25/03/2021 01:12, Jakub Kicinski wrote:
> Drivers should reject mixing %ETHTOOL_FEC_AUTO_BIT with other
> + * FEC modes, because it's unclear whether in this case other modes constrain
> + * AUTO or are independent choices.
Does this mean you want me to spin a patch to sfc to reject this?
Curre
On 15/04/2021 10:03, Trevor Hemsley wrote:
> Hi,
>
> I run Fedora 32 and since kernels in the 5.10 series I have been unable to
> boot without getting a panic in the sfc module. I tried on 5.11.12 tonight
> and the crash still occurs. I have tried reporting this via Fedora channels
> but the si
On 28/02/2021 17:05, Alexey Dobriyan wrote:
> From 251ca5673886b5bb0a42004944290b9d2b267a4a Mon Sep 17 00:00:00 2001
> From: Alexey Dobriyan
> Date: Fri, 19 Feb 2021 13:37:24 +0300
> Subject: [PATCH 10/11] pragma once: delete few backslashes
>
> Some macros contain one backslash too many and end
"net: Fix packet reordering caused by GRO and listified
> RX cooperation")
> Signed-off-by: Eric Dumazet
> Bisected-by: John Sperbeck
> Tested-by: Jian Yang
> Cc: Maxim Mikityanskiy
> Cc: Alexander Lobakin
> Cc: Saeed Mahameed
> Cc: Edward Cree
Reviewed-by: Edward Cree
On 05/02/2021 12:47, Bhaskar Chowdhury wrote:
>
>
> s/fuck/mess/
> s/fucking/s/
>
> Signed-off-by: Bhaskar Chowdhury
Right or wrong, these are not "spelling fixes".
Please do not misrepresent your patch in your Subject: line.
(Also, subsystem prefix should probably just be "net: sunhme:".)
On 09/08/2020 01:29, Guenter Roeck wrote:
> On Mon, Aug 03, 2020 at 09:33:20PM +0100, Edward Cree wrote:
>> +if (EFX_MIN_DMAQ_SIZE % reader->value) {
> This is a 64-bit operation (value is 64 bit). Result on 32-bit builds:
>
> ERROR: modpost: "__umoddi3&
On 10/08/2020 16:51, Guenter Roeck wrote:
> On Thu, Aug 06, 2020 at 07:17:43PM +0100, Edward Cree wrote:
>> Maybe I should add a
>>
>> static inline u32 mod_u64(u64 dividend, u32 divisor)
>> {
>> return do_div(dividend, divisor);
>> }
> Your
r min-size; if the granularity <= EFX_MIN_DMAQ_SIZE then it fits
in 32 bits, so we can cast it to u32 for the divide.
Reported-by: kernel test robot
Signed-off-by: Edward Cree
---
I've only build-tested this, and then only on 64-bit, since our lab's
cooling system can't cope w
On 13/08/2020 15:39, Christophe Leroy wrote:
> ppc6xx_defconfig fails building sfc.ko module, complaining
> about the lack of _umoddi3 symbol.
>
> This is due to the following test
>
> if (EFX_MIN_DMAQ_SIZE % reader->value) {
>
> Because reader->value is u64.
Already fixed in net.git
On EF100, the RX hash field in the packet prefix may not be valid (e.g.
if the header parse failed), and this is indicated by a one-bit flag
elsewhere in the packet prefix. Only call skb_set_hash() if the
RSS_HASH_VALID bit is set.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc
Fix up some bugs in the initial EF100 submission, and re-fix
the hash_valid fix which was incomplete.
The reset bugs are currently hard to trigger; they were found
with an in-progress patch adding ethtool support, whereby
ethtool --reset reliably reproduces them.
Edward Cree (4):
sfc
er table management and related
gubbins")
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef100_nic.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/sfc/ef100_nic.c
b/drivers/net/ethernet/sfc/ef100_nic.c
index b8a7e9ed7913..19fe86b3b316
ading to a panic.
To prevent this, after freeing it, overwrite it with NULL.
Fixes: a9dc3d5612ce ("sfc_ef100: RX filter table management and related
gubbins")
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/rx_common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/driver
Actually hook up the .rx_buf_hash_valid method in EF100's nic_type.
Fixes: 068885434ccb ("sfc: check hash is valid before using it")
Reported-by: Martin Habets
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef100_nic.c | 2 ++
1 file changed, 2 insertions(+)
diff --gi
the new efx->irqs_hooked flag.
Fixes: 965b549f3c20 ("sfc_ef100: implement ndo_open/close and EVQ probing")
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/net_driver.h | 2 ++
drivers/net/ethernet/sfc/nic.c| 4
2 files changed, 6 insertions(+)
diff --git
On 19/08/2020 01:28, Randy Dunlap wrote:
> Hi,
>
> Does the drivers/net/ethernet/sfc/sfc driver require (expect)
> dma_addr_t to be 64 bits (as opposed to 32 bits)?
>
> I see that several #defines in ef100_regs.h are 64...
>
> When used with DMA_BIT_MASK(64), does the value just need to be
> trunca
Truncation of DMA_BIT_MASK to 32-bit dma_addr_t is semantically safe,
but the compiler was warning because it was happening implicitly.
Insert explicit casts to suppress the warnings.
Reported-by: Randy Dunlap
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef100.c | 8
1
rnel test robot
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef100_rx.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/sfc/ef100_rx.c
b/drivers/net/ethernet/sfc/ef100_rx.c
index 012925e878f4..85207acf7dee 100644
--- a/drivers/net/ethernet
On 14/06/2019 15:33, John Hurley wrote:
> Instead of
> returning TC_ACT_REINSERT, change the type to the new TC_ACT_CONSUMED
> which tells the caller that the packet has been stolen by another process
> and that no consume call is required.
Possibly a dumb question, but why does this need a new CON
On 14/06/2019 16:13, Jiong Wang wrote:
> Just an update and keep people posted.
>
> Working on linked list based approach, the implementation looks like the
> following, mostly a combine of discussions happened and Naveen's patch,
> please feel free to comment.
>
> - Use the reserved opcode 0xf0
On 17/06/2019 20:59, Jiong Wang wrote:
> Edward Cree writes:
>
>> On 14/06/2019 16:13, Jiong Wang wrote:
>>> Just an update and keep people posted.
>>>
>>> Working on linked list based approach, the implementation looks like the
>>> following, mostl
On 17/06/2019 21:40, Jiong Wang wrote:
> Now if we don't split patch when patch an insn inside patch, instead, if we
> replace the patched insn using what you suggested, then the logic looks to
> me becomes even more complex, something like
>
>for (idx = 0; idx < insn_cnt; idx++) {
> if (i
Owing to a missing conditional, the result of rps_may_expire_flow() was
being ignored and filters were being removed even if we'd decided not to
expire them.
Fixes: f8d6203780b7 ("sfc: ARFS filter IDs")
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef10.c | 5 +++--
back into an index (which is
what the remove call in the expiry path expects, anyway).
Fixes: 3af0f34290f6 ("sfc: replace asynchronous filter operations")
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/rx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/eth
A couple more bits of breakage in my recent ARFS and async filters work.
Patch #1 in particular fixes a bug that leads to memory trampling and
consequent crashes.
Edward Cree (2):
sfc: Use filter index rather than ID for rps_flow_id table
sfc: fix ARFS expiry check on EF10
drivers/net
On 30/04/18 02:31, Wenwen Wang wrote:
> In ethtool_get_rxnfc(), the object "info" is firstly copied from
> user-space. If the FLOW_RSS flag is set in the member field flow_type of
> "info" (and cmd is ETHTOOL_GRXFH), info needs to be copied again from
> user-space because FLOW_RSS is newer and has
1 - 100 of 1233 matches
Mail list logo
