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
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
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 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
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 +-
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
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 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 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
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 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:".)
"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 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
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
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
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
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
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 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 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 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 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 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 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
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_
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-
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
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
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
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
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 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 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 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 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 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
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
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
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
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
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
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
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 Mon, Sep 28 2020 at 21:05, Edward Cree wrote:
>> Only compile-tested so far, because I'm waiting for my kernel to
>> finish rebuilding with CONFIG_DEBUG_ATOMIC_SLEEP
I've now tested and confirmed that the might_sleep warning goes
away with this patch.
Thomas, do
thods, which are happy with being
called from atomic contexts.
Fixes: f00bf2305cab ("sfc: don't update stats on VF when called in atomic
context")
Reported-by: Sebastian Andrzej Siewior
Signed-off-by: Edward Cree
---
Only compile-tested so far, because I'm waiting for my ker
() check and the code concerned
doesn't seemto have changed a great deal since.
Anyway, this fix looks correct, and you can have my
Acked-by: Edward Cree
but I thinkit might be cleaner to avoid having to have this unused
can_sleep argument on all the NICs that don't need it, by instead
On 18/09/2020 15:33, Dan Carpenter wrote:
> This failure path should return a negative error code but it currently
> returns success.
>
> Fixes: 51b35a454efd ("sfc: skeleton EF100 PF driver")
> Signed-off-by: Dan Carpenter
Acked-by: Edward Cree
Thanks for catching this.
AX' not described in 'efx_ptp_data'
>
> After some discussion on the list, break this patch out to
> a separate one, and fix the issue through a creative
> macro declaration.
>
> Signed-off-by: Jesse Brandeburg
> Cc: Edward Cree
I still don't love it, but
ng code, and
> occasionally, just mark the variable as maybe unused since it
> could be used in an ifdef or debug scenario.
>
> Only compile tested with W=1.
>
> Signed-off-by: Jesse Brandeburg
For sfc/falcon:
Acked-by: Edward Cree
On 11/09/2020 23:26, Jakub Kicinski wrote:
> "Toolchain" sounds a little grand in this context, the script that
> parses kdoc does basic regexps to convert the standard kernel macros:
> ...
> IDK if we can expect it to understand random driver's macros..
I wasn't suggesting it should _understand_ t
Necessitates an .ndo_features_check, as the EF10 datapath has several
limitations on what it can handle.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef10.c | 16 +
drivers/net/ethernet/sfc/efx.c| 1 +
drivers/net/ethernet/sfc/efx_common.c | 84
>From the 8000 series onwards, EF10 NICs with suitable firmware are able
to perform TSO within VXLAN or NVGRE encapsulation.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef10.c | 55 ---
drivers/net/ethernet/sfc/net_driver.h | 5 +++
2 files chan
ng it.
In efx_mcdi_tx_init(), report back failure to obtain a TSOv2 context by
setting tx_queue->tso_version to 0, which will cause the TX path to
use the GSO-based fallback.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef10.c | 35 +--
drivers/net/ethernet/sf
Nothing yet creates inner csum TXQs; just change all references to
EFX_TXQ_TYPE_OFFLOAD to the new EFX_TXQ_TYPE_OUTER_CSUM.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef10.c | 4 ++--
drivers/net/ethernet/sfc/farch.c | 4 ++--
drivers/net/ethernet/sfc
efx_hard_start_xmit().
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef10.c | 5 ++--
drivers/net/ethernet/sfc/efx_channels.c | 10 +++
drivers/net/ethernet/sfc/ethtool_common.c | 2 +-
drivers/net/ethernet/sfc/farch.c | 20 +++---
drivers/net/ethernet/sfc
If the MC reports the VXLAN_NVGRE datapath capability, then these queues
can be used for checksum offload of encapsulated packets.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef10.c | 23 ---
drivers/net/ethernet/sfc/mcdi_functions.c | 16
Won't actually be exercised until we start advertising the corresponding
offload features.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ptp.c | 3 ++-
drivers/net/ethernet/sfc/tx.c | 2 +-
drivers/net/ethernet/sfc/tx.h | 26 ++
3 files change
t inspired the wrong version)
* Add comment in patch #5 explaining what the deal with TSOv3 is
Edward Cree (7):
sfc: decouple TXQ type from label
sfc: define inner/outer csum offload TXQ types
sfc: create inner-csum queues on EF10 if supported
sfc: select inner-csum-offload TX queues for
On 11/09/2020 22:42, Jesse Brandeburg wrote:
> Thanks Ed, I think I might just remove the /** on that function then
> (removing it from kdoc processing)
I dunno, that means
a) kerneldoc won't generate html for this struct
b) new additions to the struct without corresponding kerneldoc won't
gener
The statement above it already returns, so there is no way to get here.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef100_tx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/sfc/ef100_tx.c
b/drivers/net/ethernet/sfc/ef100_tx.c
index 078c7ec2a70e
The old_channel argument is never used, so remove it.
The function is only called from elsewhere in efx_channels.c, so make
it static and remove the declaration from the header file.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/efx_channels.c | 5 ++---
drivers/net/ethernet/sfc
efx_init_struct already calls this, we don't need to do it again.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef100_nic.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/sfc/ef100_nic.c
b/drivers/net/ethernet/sfc/ef100_nic.c
index fb7752d
Clean up a few nits I noticed while working on TXQ stuff.
Edward Cree (3):
sfc: remove duplicate call to efx_init_channels from EF100 probe
sfc: remove spurious unreachable return statement
sfc: cleanups around efx_alloc_channel
drivers/net/ethernet/sfc/ef100_nic.c| 4
drivers
On 11/09/2020 17:01, Jakub Kicinski wrote:
> On Thu, 10 Sep 2020 21:33:11 +0100 Edward Cree wrote:
>> index 078c7ec2a70e..272eb5ecb7e7 100644
>> --- a/drivers/net/ethernet/sfc/ef100_tx.c
>> +++ b/drivers/net/ethernet/sfc/ef100_tx.c
>> @@ -38,7 +38,8 @@ void ef100_
On 11/09/2020 16:53, Jakub Kicinski wrote:
> On Thu, 10 Sep 2020 21:31:29 +0100 Edward Cree wrote:
>> diff --git a/drivers/net/ethernet/sfc/tx.c b/drivers/net/ethernet/sfc/tx.c
>> index 48d91b26f1a2..b0a08d9f4773 100644
>> --- a/drivers/net/ethernet/sfc/tx.c
>> +++ b/dr
On 11/09/2020 02:23, Jesse Brandeburg wrote:
> As part of the W=1 cleanups for ethernet, a million [1] driver comments
> had to be cleaned up to get the W=1 compilation to succeed. This
> change finally makes the drivers/net/ethernet tree compile with
> W=1 set on the command line.
>
> [1] - ok it
ng code, and
> occasionally, just mark the variable as maybe unused since it
> could be used in an ifdef or debug scenario.
>
> Only compile tested with W=1 and an allyesconfig with all the
> network drivers turned into modules (to try to test all options).
>
> Signed-off-by: Jesse
EF10 NICs from the 8000 series onwards support TX offloads (checksumming,
TSO) on VXLAN- and NVGRE-encapsulated packets. This series adds driver
support for these offloads.
Edward Cree (7):
sfc: decouple TXQ type from label
sfc: define inner/outer csum offload TXQ types
sfc: create inner
Nothing yet creates inner csum TXQs; just change all references to
EFX_TXQ_TYPE_OFFLOAD to the new EFX_TXQ_TYPE_OUTER_CSUM.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef10.c | 4 ++--
drivers/net/ethernet/sfc/farch.c | 4 ++--
drivers/net/ethernet/sfc
If the MC reports the VXLAN_NVGRE datapath capability, then these queues
can be used for checksum offload of encapsulated packets.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef10.c | 23 ---
drivers/net/ethernet/sfc/mcdi_functions.c | 16
>From the 8000 series onwards, EF10 NICs with suitable firmware are able
to perform TSO within VXLAN or NVGRE encapsulation.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef10.c | 55 ---
drivers/net/ethernet/sfc/net_driver.h | 5 +++
2 files chan
Won't actually be exercised until we start advertising the corresponding
offload features.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ptp.c | 3 ++-
drivers/net/ethernet/sfc/tx.c | 2 +-
drivers/net/ethernet/sfc/tx.h | 26 ++
3 files change
Necessitates an .ndo_features_check, as the EF10 datapath has several
limitations on what it can handle.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef10.c | 16 +
drivers/net/ethernet/sfc/efx.c| 1 +
drivers/net/ethernet/sfc/efx_common.c | 84
ill cause the TX path to
use the GSO-based fallback.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef10.c | 35 +--
drivers/net/ethernet/sfc/ef100_tx.c | 3 +-
drivers/net/ethernet/sfc/farch.c | 2 ++
drivers/net/ethernet/sfc/mcdi_functio
Make it possible to have an arbitrary mapping from types to labels,
because when we add inner-csum-offload TXQs there will no longer be a
convenient nesting hierarchy of NIC types (EF10 will have inner-csum
TXQs, while Siena will have HIGHPRI).
Signed-off-by: Edward Cree
---
drivers/net
The code recently moved into this file contained a number of coding style
issues, about which checkpatch and xmastree complained. Fix them.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/mcdi_port_common.c | 23 +++--
drivers/net/ethernet/sfc/mcdi_port_common.h | 2
On 07/09/2020 20:22, Jakub Kicinski wrote:
> On Mon, 7 Sep 2020 17:14:34 +0100 Edward Cree wrote:
>> drivers/net/ethernet/sfc/mcdi_port.c| 593 +---
>> drivers/net/ethernet/sfc/mcdi_port_common.c | 560 ++
> Would you mind improving var
code movement so I've left the code as it is.
While patch #1 is technically a fix and possibly could go to 'net', I've
put it in this series since it only becomes triggerable with the added
'ethtool --reset' support.
Edward Cree (6):
sfc: don't double-down(
we can simply call the efx_mcdi_phy_* functions directly.
This also hooks up these functions for EF100, which was previously using
the dummy_phy_ops.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/efx.c | 17 +-
drivers/net/ethernet/sfc/efx_common.c | 26 +-
driv
Christoph says[1] that dma_set_mask_and_coherent() is smart enough to
truncate the mask itself if it's too long. So we can get rid of our
"lop off one bit and retry" loop in efx_init_io().
[1]: https://www.spinics.net/lists/netdev/msg677266.html
Signed-off-by: Edward Cree
-
responding FEC bits.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/mcdi_port_common.c | 48 +++--
drivers/net/ethernet/sfc/mcdi_port_common.h | 2 +-
2 files changed, 36 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/sfc/mcdi_port_common.c
b/drivers/ne
brought up.
Fixes: a9dc3d5612ce ("sfc_ef100: RX filter table management and related
gubbins")
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef100_nic.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/net/ethernet/sfc/ef100_nic.c
b/drivers/net/et
Mostly just calls to existing common functions.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef100_ethtool.c | 41
drivers/net/ethernet/sfc/ef100_netdev.c | 4 +++
drivers/net/ethernet/sfc/ef100_nic.c | 7 +++-
3 files changed, 51 insertions(+), 1
Per-module versions for in-tree drivers are deprecated.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/efx.c| 3 +--
drivers/net/ethernet/sfc/ethtool_common.c | 1 -
drivers/net/ethernet/sfc/net_driver.h | 2 --
3 files changed, 1 insertion(+), 5 deletions(-)
diff
All users of this function are now gone.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/nic_common.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/net/ethernet/sfc/nic_common.h
b/drivers/net/ethernet/sfc/nic_common.h
index 3f88c6444fa1..82271f0b8627 100644
Instead of open-coding the calculation with efx_tx_queue_partner(), use
the functions that iterate over numbers of queues other than 2 with
efx_for_each_channel_tx_queue().
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/net_driver.h | 4
drivers/net/ethernet/sfc/tx.c
Use efx_for_each_channel_tx_queue() rather than efx_tx_queue_partner().
Make some related simplifications of efx_nic_tx_is_empty() to remove
entry points that aren't used.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/nic_common.h | 30 ++-
driver
ore for the call to
efx_tx_send_pending(), which will clear xmit_pending. Thus, after an
xmit_more TX, the doorbell is un-rung and xmit_pending is true.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef10.c | 2 +-
drivers/net/ethernet/sfc/ef100_tx.c | 14 +++
drivers/
As in the Siena/EF10 case, it minimises cacheline ping-pong between
the TX and completion paths.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef100_tx.c | 8 ++--
drivers/net/ethernet/sfc/net_driver.h | 14 ++
2 files changed, 20 insertions(+), 2 deletions
it, make ef100_notify_tx_desc static since nothing
outside of ef100_tx.c uses it.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef100_tx.c | 22 +++---
drivers/net/ethernet/sfc/ef100_tx.h | 1 -
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/net/
consistency
Edward Cree (6):
sfc: add and use efx_tx_send_pending in tx.c
sfc: make ef100 xmit_more handling look more like ef10's
sfc: use tx_queue->old_read_count in EF100 TX path
sfc: use efx_channel_tx_[old_]fill_level() in Siena/EF10 TX datapath
sfc: rewrite efx_tx_may_pio
sfc
On 02/09/2020 23:55, David Miller wrote:
> From: Edward Cree
> Date: Wed, 2 Sep 2020 15:35:53 +0100
>
>> +tx_queue->xmit_more_available = true;
>
> I don't understand why you're setting xmit_more_available
> unconditionally to true now instead of settin
All users of this function are now gone.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/nic_common.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/net/ethernet/sfc/nic_common.h
b/drivers/net/ethernet/sfc/nic_common.h
index 3f88c6444fa1..82271f0b8627 100644
Use efx_for_each_channel_tx_queue() rather than efx_tx_queue_partner().
Make some related simplifications of efx_nic_tx_is_empty() to remove
entry points that aren't used.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/nic_common.h | 30 ++-
driver
Instead of open-coding the calculation with efx_tx_queue_partner(), use
the functions that iterate over numbers of queues other than 2 with
efx_for_each_channel_tx_queue().
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/net_driver.h | 4
drivers/net/ethernet/sfc/tx.c
As in the Siena/EF10 case, it minimises cacheline ping-pong between
the TX and completion paths.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef100_tx.c | 8 ++--
drivers/net/ethernet/sfc/net_driver.h | 14 ++
2 files changed, 20 insertions(+), 2 deletions
Instead of using efx_tx_queue_partner(), which relies on the assumption
that tx_queues_per_channel is 2, efx_tx_send_pending() iterates over
txqs with efx_for_each_channel_tx_queue().
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/tx.c | 59 ++-
1 file
we can have more (e.g. for handling inner-header checksums) or
fewer (e.g. to free up hardware queues for XDP usage).
Edward Cree (5):
sfc: add and use efx_tx_send_pending in tx.c
sfc: use tx_queue->old_read_count in EF100 TX path
sfc: use efx_channel_tx_[old_]fill_level() in Siena/EF10
hat the break does the right
thing. Use u64 for 'count' and 'i' to prevent overflow in case of
(unreasonably) large values of id.data and n.
Signed-off-by: Edward Cree
---
net/ethtool/ioctl.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
d
type method, so remove that and just call
efx_mcdi_set_id_led() directly.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef10.c | 2 --
drivers/net/ethernet/sfc/ethtool.c| 3 +--
drivers/net/ethernet/sfc/mcdi.c | 6 ++
drivers/net/ethernet/sfc/mcdi.h | 2 +-
drive
1 - 100 of 1233 matches
Mail list logo
