Re: [Intel-wired-lan] [PATCH iwl-next v4 05/12] ice: Log virtual channel messages in PF
On 11/30/2023 1:12 AM, Simon Horman wrote:
On Tue, Nov 21, 2023 at 02:51:04AM +, Yahui Cao wrote:
From: Lingyu Liu
Save the virtual channel messages sent by VF on the source side during
runtime. The logged virtchnl messages will be transferred and loaded
into the device on the destination side during the device resume stage.
For the feature which can not be migrated yet, it must be disabled or
blocked to prevent from being abused by VF. Otherwise, it may introduce
functional and security issue. Mask unsupported VF capability flags in
the VF-PF negotiaion stage.
Signed-off-by: Lingyu Liu
Signed-off-by: Yahui Cao
Hi Lingyu Liu and Yahui Cao,
some minor feedback from my side.
...
diff --git a/drivers/net/ethernet/intel/ice/ice_migration.c
b/drivers/net/ethernet/intel/ice/ice_migration.c
...
+/**
+ * ice_migration_log_vf_msg - Log request message from VF
+ * @vf: pointer to the VF structure
+ * @event: pointer to the AQ event
+ *
+ * Log VF message for later device state loading during live migration
+ *
+ * Return 0 for success, negative for error
+ */
+int ice_migration_log_vf_msg(struct ice_vf *vf,
+struct ice_rq_event_info *event)
+{
+ struct ice_migration_virtchnl_msg_listnode *msg_listnode;
+ u32 v_opcode = le32_to_cpu(event->desc.cookie_high);
+ struct device *dev = ice_pf_to_dev(vf->pf);
+ u16 msglen = event->msg_len;
+ u8 *msg = event->msg_buf;
+
+ if (!ice_migration_is_loggable_msg(v_opcode))
+ return 0;
+
+ if (vf->virtchnl_msg_num >= VIRTCHNL_MSG_MAX) {
+ dev_warn(dev, "VF %d has maximum number virtual channel
commands\n",
+vf->vf_id);
+ return -ENOMEM;
+ }
+
+ msg_listnode = (struct ice_migration_virtchnl_msg_listnode *)
+ kzalloc(struct_size(msg_listnode,
+ msg_slot.msg_buffer,
+ msglen),
+ GFP_KERNEL);
nit: there is no need to cast the void * pointer returned by kzalloc().
Flagged by Coccinelle.
Sure. Will fix in next version.
+ if (!msg_listnode) {
+ dev_err(dev, "VF %d failed to allocate memory for msg
listnode\n",
+ vf->vf_id);
+ return -ENOMEM;
+ }
+ dev_dbg(dev, "VF %d save virtual channel command, op code: %d, len:
%d\n",
+ vf->vf_id, v_opcode, msglen);
+ msg_listnode->msg_slot.opcode = v_opcode;
+ msg_listnode->msg_slot.msg_len = msglen;
+ memcpy(msg_listnode->msg_slot.msg_buffer, msg, msglen);
+ list_add_tail(&msg_listnode->node, &vf->virtchnl_msg_list);
+ vf->virtchnl_msg_num++;
+ vf->virtchnl_msg_size += struct_size(&msg_listnode->msg_slot,
+msg_buffer,
+msglen);
+ return 0;
+}
+
+/**
+ * ice_migration_unlog_vf_msg - revert logged message
+ * @vf: pointer to the VF structure
+ * @v_opcode: virtchnl message operation code
+ *
+ * Remove the last virtual channel message logged before.
+ */
+void ice_migration_unlog_vf_msg(struct ice_vf *vf, u32 v_opcode)
+{
+ struct ice_migration_virtchnl_msg_listnode *msg_listnode;
+
+ if (!ice_migration_is_loggable_msg(v_opcode))
+ return;
+
+ if (WARN_ON_ONCE(list_empty(&vf->virtchnl_msg_list)))
+ return;
+
+ msg_listnode =
+ list_last_entry(&vf->virtchnl_msg_list,
+ struct ice_migration_virtchnl_msg_listnode,
+ node);
+ if (WARN_ON_ONCE(msg_listnode->msg_slot.opcode != v_opcode))
+ return;
+
+ list_del(&msg_listnode->node);
+ kfree(msg_listnode);
msg_listnode is freed on the line above,
but dereferenced in the usage of struct_size() below.
As flagged by Smatch and Coccinelle.
>> + vf->virtchnl_msg_num--;
+ vf->virtchnl_msg_size -= struct_size(&msg_listnode->msg_slot,
+msg_buffer,
+msg_listnode->msg_slot.msg_len);
+}
...
Good catch :) Will fix in next version
Thanks.
Yahui.
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] [PATCH iwl-next] ice: ice_base.c: Add const modifier to params and vars
On Wed, Nov 29, 2023 at 02:36:11AM -0500, Jan Glaza wrote: > Add const modifier to function parameters and variables where appropriate > in ice_base.c and corresponding declarations in ice_base.h. > > The reason for starting the change is that read-only pointers should be > marked as const when possible to allow for smoother and more optimal code > generation and optimization as well as allowing the compiler to warn the > developer about potentially unwanted modifications, while not carrying > noticable negative impact. Hi Jan, it's probably not worth respinning for this, but: noticeable > > Reviewed-by: Andrii Staikov > Reviewed-by: Sachin Bahadur > Signed-off-by: Jan Glaza > --- > This change is done in one file to get comment feedback and, if positive, > will be rolled out across the entire ice driver code. The nit above notwithstanding, this looks good to me. Reviewed-by: Simon Horman ___ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] [EXT] [PATCH iwl-net v2 1/2] igc: Report VLAN EtherType matching back to user
Hi Suman,
On Fri Dec 01 2023, Suman Ghosh wrote:
> Hi Kurt,
>
>
>>+ if (rule->filter.match_flags & IGC_FILTER_FLAG_VLAN_ETYPE) {
>>+ fsp->flow_type |= FLOW_EXT;
>>+ fsp->h_ext.vlan_etype = rule->filter.vlan_etype;
>>+ fsp->m_ext.vlan_etype = ETHER_TYPE_FULL_MASK;
> [Suman] User can provide mask for vlan-etype as well. Why not take
> that rather than hard coding it? I checked you are already doing the
> same for TCI in the other patch.
Currently the driver allows/supports to match the VLAN EtherType only by
full mask. That is different from TCI, where two different mask values
are possible.
Thanks,
Kurt
signature.asc
Description: PGP signature
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] Compile of out-of-tree 'ice' driver fails on 32 bit
> > Has anyone tried compiling the out-of-tree kernel network software
> > for the 'ice' driver on 32 bit i386? I tried it for the
> > long-term-support 5.10.197 kernel and got these compile time errors:
>
> Are those regressions?
> Have you tried 1.12.x?
> We will also soon release also 1.13.x
I just tried 1.11.14, 1.11.17.1, and 1.12.7. They all had similar
compile failures.
> $ make ARCH=i386 CFLAGS_EXTRA="-DGNSS_SUPPORT"
> > make ccflags-y="-DGNSS_SUPPORT -DUSE_INTEL_AUX_BUS" -C
> > "/lib/modules/5.10.197.i686-pentium4-mpentium4-lenovo/source"
> > CONFIG_ICE=m CONFIG_MODULE_SIG=n CONFIG_MODULE_SIG_ALL=
> > M="/tmp/ice-1.11.14/src" NEED_AUX_BUS="2" modules
> >CC [M] /tmp/ice-1.11.14/src/ice_main.o
> > In file included from /tmp/ice-1.11.14/src/kcompat.h:3351,
> > from /tmp/ice-1.11.14/src/ice.h:7,
> > from /tmp/ice-1.11.14/src/ice_main.c:8:
> > /tmp/ice-1.11.14/src/kcompat_impl.h:851:20: error: redefinition of
> > ‘eth_hw_addr_set’
> >851 | static inline void eth_hw_addr_set(struct net_device *dev,
> > const u8 *addr)
> >|^~~
> > In file included from /tmp/ice-1.11.14/src/kcompat.h:16:
> > ./include/linux/etherdevice.h:309:20: note: previous definition of
> > ‘eth_hw_addr_set’ with type ‘void(struct net_device *, const u8 *)’
> > {aka ‘void(struct net_device *, const unsigned char *)’}
> >309 | static inline void eth_hw_addr_set(struct net_device *dev,
> > const u8 *addr)
>
> That particular thing could be rather easily solved,
> for official fix, 1.14 would be the earliest, but let me know how it
> works with 1.12.x so I could prepare some patch for you.
>
> >|^~~
> > In file included from ./include/linux/bits.h:6,
> > from ./include/linux/bitops.h:5,
> > from ./include/linux/kernel.h:12,
> > from ./include/asm-generic/bug.h:20,
> > from ./arch/x86/include/asm/bug.h:93,
> > from ./include/linux/bug.h:5,
> > from ./include/linux/io.h:11,
> > from /tmp/ice-1.11.14/src/kcompat.h:13:
> > /tmp/ice-1.11.14/src/ice_main.c: In function ‘ice_pf_fwlog_is_input_valid’:
> > ./include/vdso/bits.h:7:40: warning: left shift count >= width of type
> > [-Wshift-count-overflow]
> > 7 | #define BIT(nr) (UL(1) << (nr))
> >|^~
> > /tmp/ice-1.11.14/src/ice_main.c:5992:23: note: in expansion of macro ‘BIT’
> > 5992 | if (events >= BIT(ICE_AQC_FW_LOG_ID_MAX)) {
> >| ^~~
> > ./include/vdso/bits.h:7:40: warning: left shift count >= width of type
> > [-Wshift-count-overflow]
> > 7 | #define BIT(nr) (UL(1) << (nr))
> >|^~
> > ./include/linux/dev_printk.h:112:39: note: in expansion of macro ‘BIT’
> >112 | _dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
> >| ^~~
> > /tmp/ice-1.11.14/src/ice_main.c:5993:17: note: in expansion of macro
> > ‘dev_err’
> > 5993 | dev_err(ice_pf_to_dev(pf), "Invalid FW log
> > events 0x%lx, all FW log event bits >= 0x%lx are invalid\n",
> >| ^~~
> > make[2]: *** [scripts/Makefile.build:286:
> > /tmp/ice-1.11.14/src/ice_main.o] Error 1
> > make[1]: *** [Makefile:1832: /tmp/ice-1.11.14/src] Error 2
> > make: *** [Makefile:149: all] Error 2
> >
> > I know 32bit is officially unsupported, but it seems like it should
> > not break the compile this badly.
>
> I would say it's better to fail at that stage that render out-of-bound
> writes or other errors.
>
> looks like Intel OOT BIT() macro assumes 64bit arch, perhaps this could
> be fixed in general, but I'm not promising anything here.
>
Maybe they should declare the variable as u64 instead of unsigned
long? The macro BIT in include/vdso/bits.h is defined as:
#define BIT(nr) (UL(1) << (nr))
So you get whatever an unsigned long is per architecture, which
obviously varies.
- Matthew
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] [PATCH iwl-net] i40e: Fix kernel crash during macvlan offloading setup
On 30. 11. 23 20:24, Brelinski, Tony wrote:
-Original Message-
From: Intel-wired-lan On Behalf Of
Simon Horman
Sent: Wednesday, November 29, 2023 8:36 AM
To: ivecera
Cc: Harshitha Ramamurthy; Drewek,
Wojciech;net...@vger.kernel.org;
Brandeburg, Jesse; open list ; Eric Dumazet ; Nguyen,
Anthony L; Jeff Kirsher
; moderated list:INTEL ETHERNET DRIVERS ; Keller, Jacob E ; Jakub
Kicinski; Paolo Abeni; David S.
Miller
Subject: Re: [Intel-wired-lan] [PATCH iwl-net] i40e: Fix kernel crash during
macvlan offloading setup
On Fri, Nov 24, 2023 at 05:42:33PM +0100, Ivan Vecera wrote:
Function i40e_fwd_add() computes num of created channels and num of
queues per channel according value of pf->num_lan_msix.
This is wrong because the channels are used for subordinated net
devices that reuse existing queues from parent net device and number
of existing queue pairs (pf->num_queue_pairs) should be used instead.
E.g.:
Let's have (pf->num_lan_msix == 32)... Then we reduce number of
combined queues by ethtool to 8 (so pf->num_queue_pairs == 8).
i40e_fwd_add() called by macvlan then computes number of macvlans
channels to be 16 and queues per channel 1 and calls
i40e_setup_macvlans(). This computes new number of queue pairs for PF
as:
num_qps = vsi->num_queue_pairs - (macvlan_cnt * qcnt);
This is evaluated in this case as:
num_qps = (8 - 16 * 1) = (u16)-8 = 0xFFF8
...and this number is stored vsi->next_base_queue that is used during
channel creation. This leads to kernel crash.
Fix this bug by computing the number of offloaded macvlan devices and
no. their queues according the current number of queues instead of
maximal one.
Reproducer:
1) Enable l2-fwd-offload
2) Reduce number of queues
3) Create macvlan device
4) Make it up
Result:
[root@cnb-03 ~]# ethtool -K enp2s0f0np0 l2-fwd-offload on
[root@cnb-03 ~]# ethtool -l enp2s0f0np0 | grep Combined
Combined: 32
Combined: 32
[root@cnb-03 ~]# ethtool -L enp2s0f0np0 combined 8
[root@cnb-03 ~]# ip link add link enp2s0f0np0 mac0 type macvlan mode
bridge
[root@cnb-03 ~]# ip link set mac0 up
...
[ 1225.686698] i40e :02:00.0: User requested queue count/HW max
RSS count: 8/32 [ 1242.399103] BUG: kernel NULL pointer dereference,
address: 0118 [ 1242.406064] #PF: supervisor write access
in kernel mode [ 1242.411288] #PF: error_code(0x0002) - not-present
page [ 1242.416417] PGD 0 P4D 0 [ 1242.418950] Oops: 0002 [#1]
PREEMPT
SMP NOPTI [ 1242.423308] CPU: 26 PID: 2253 Comm: ip Kdump: loaded
Not
tainted 6.7.0-rc1+ #20 [ 1242.430607] Hardware name: Abacus electric,
s.r.o. -ser...@abacus.cz Super Server/H12SSW-iN, BIOS 2.4 04/13/2022
[ 1242.440850] RIP:
0010:i40e_channel_config_tx_ring.constprop.0+0xd9/0x180 [i40e] [
1242.448165] Code: 48 89 b3 80 00 00 00 48 89 bb 88 00 00 00 74 3c 31
c9 0f b7 53 16 49 8b b4 24 f0 0c 00 00 01 ca 83 c1 01 0f b7 d2 48 8b
34 d6 <48> 89 9e 18 01 00 00 49 8b b4 24 e8 0c 00 00 48 8b 14 d6 48 89
9a [ 1242.466902] RSP: 0018:a4d52cd2f610 EFLAGS: 00010202 [
1242.472121] RAX: RBX: 9390a4ba2e40 RCX:
0001 [ 1242.479244] RDX: fff8 RSI:
RDI: [ 1242.486370] RBP:
a4d52cd2f650 R08: 0020 R09: [
1242.493494] R10: R11: 00010001 R12:
9390b861a000 [ 1242.500626] R13: 00a0 R14:
0010 R15: 9390b861a000 [ 1242.507751] FS:
7efda536b740() GS:939f4ec8()
knlGS: [ 1242.515826] CS: 0010 DS: ES:
CR0: 80050033 [ 1242.521564] CR2: 0118 CR3:
00010bd48002 CR4: 00770ef0 [ 1242.528699] PKRU:
5554 [ 1242.531400] Call Trace:
[ 1242.533846]
[ 1242.535943] ? __die+0x20/0x70
[ 1242.539004] ? page_fault_oops+0x76/0x170 [ 1242.543018] ?
exc_page_fault+0x65/0x150 [ 1242.546942] ?
asm_exc_page_fault+0x22/0x30 [ 1242.551131] ?
i40e_channel_config_tx_ring.constprop.0+0xd9/0x180 [i40e] [
1242.557847] i40e_setup_channel.part.0+0x5f/0x130 [i40e] [
1242.563167] i40e_setup_macvlans.constprop.0+0x256/0x420 [i40e] [
1242.569099] i40e_fwd_add+0xbf/0x270 [i40e] [ 1242.573300]
macvlan_open+0x16f/0x200 [macvlan] [ 1242.577831]
__dev_open+0xe7/0x1b0 [ 1242.581236]
__dev_change_flags+0x1db/0x250
...
Fixes: 1d8d80b4e4ff ("i40e: Add macvlan support on i40e")
Signed-off-by: Ivan Vecera
Thanks Ivan,
I agree with the analysis and that the problem was introduced by the cited
patch.
Reviewed-by: Simon Horman
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
The issue this patch is supposed to fix is resolved by this patch, but now
there is a new crash seen with this patch. Crash output below:
Crash logs:
[ 315.844666] i40e :86:00.0: Query for DCB configuration failed, err -EIO
aq_err I40E_AQ_RC_EINVAL
[ 315.844678] i40e :86:00.0: DCB init failed -5, disabled
[ 315.873394] i40e 00
Re: [Intel-wired-lan] [PATCH net-next v5 03/14] page_pool: avoid calling no-op externals when possible
From: Yunsheng Lin Date: Thu, 30 Nov 2023 20:20:44 +0800 > On 2023/11/30 19:58, Alexander Lobakin wrote: >> From: Yunsheng Lin >> Date: Thu, 30 Nov 2023 16:46:11 +0800 >> >>> On 2023/11/29 21:17, Alexander Lobakin wrote: From: Yunsheng Lin Date: Wed, 29 Nov 2023 11:17:50 +0800 > On 2023/11/27 22:32, Alexander Lobakin wrote: >> >> Chris, any thoughts on a global flag for skipping DMA syncs ladder? > > It seems there was one already in the past: > > https://lore.kernel.org/netdev/7c55a4d7-b4aa-25d4-1917-f6f355bd7...@arm.com/T/ It addresses a different problem, meaningless indirect calls, while this one addresses meaningless direct calls :> When the above gets merged, we could combine these two into one global, but Eric wasn't active with his patch and I remember there were some problems, so I wouldn't count on that it will arrive soon. >>> >>> I went through the above patch, It seems to me that there was no >>> fundamental problem that stopping us from implementing it in the dma >>> layer basing on Eric' patch if Eric is no longer interested in working >>> on a newer version? >> >> I'm somewhat interested in continuing working on Eric's patch, but not >> now. Have some urgent projects to work on, I could take this in January >> I guess... >> This PP-specific shortcut was done earlier and gives good boosts. It >> would be trivial to remove it together with the XSk shortcut once a >> generic both indirect and direct call DMA shortcut lands. >> Does this sounds good / justified enough? Or you and other >> reviewers/maintainers would prefer to wait for the generic one without >> taking this patch? >> > > I would prefer we could wait for the generic one as there is only about one > month between now and january:) Ok, let's do it this way. I'll try to revive Eric's idea soon and get it taken if he doesn't mind :> Thanks, Olek ___ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] [PATCH iwl-next v1] idpf: refactor some missing field get/prep conversions
From: Jesse Brandeburg
Date: Thu, 30 Nov 2023 13:45:11 -0800
> Most of idpf correctly uses FIELD_GET and FIELD_PREP, but a couple spots
> were missed so fix those.
>
> This conversion was automated via a coccinelle script as posted with the
> previous series.
>
> Signed-off-by: Jesse Brandeburg
> ---
> This patch should be applied after the larger FIELD_PREP/FIELD_GET
> conversion series for the Intel drivers.
> ---
> .../ethernet/intel/idpf/idpf_singleq_txrx.c| 7 +++
> drivers/net/ethernet/intel/idpf/idpf_txrx.c| 18 --
> 2 files changed, 11 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_singleq_txrx.c
> b/drivers/net/ethernet/intel/idpf/idpf_singleq_txrx.c
> index 81288a17da2a..447753495c53 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf_singleq_txrx.c
> +++ b/drivers/net/ethernet/intel/idpf/idpf_singleq_txrx.c
> @@ -328,10 +328,9 @@ static void idpf_tx_singleq_build_ctx_desc(struct
> idpf_queue *txq,
>
> if (offload->tso_segs) {
> qw1 |= IDPF_TX_CTX_DESC_TSO << IDPF_TXD_CTX_QW1_CMD_S;
> - qw1 |= ((u64)offload->tso_len << IDPF_TXD_CTX_QW1_TSO_LEN_S) &
> - IDPF_TXD_CTX_QW1_TSO_LEN_M;
> - qw1 |= ((u64)offload->mss << IDPF_TXD_CTX_QW1_MSS_S) &
> - IDPF_TXD_CTX_QW1_MSS_M;
> + qw1 |= FIELD_PREP(IDPF_TXD_CTX_QW1_TSO_LEN_M,
> + offload->tso_len);
> + qw1 |= FIELD_PREP(IDPF_TXD_CTX_QW1_MSS_M, offload->mss);
>
> u64_stats_update_begin(&txq->stats_sync);
> u64_stats_inc(&txq->q_stats.tx.lso_pkts);
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> index 1f728a9004d9..f3009d2a3c2e 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> @@ -505,7 +505,7 @@ static void idpf_rx_post_buf_refill(struct idpf_sw_queue
> *refillq, u16 buf_id)
>
> /* store the buffer ID and the SW maintained GEN bit to the refillq */
> refillq->ring[nta] =
> - ((buf_id << IDPF_RX_BI_BUFID_S) & IDPF_RX_BI_BUFID_M) |
> + FIELD_PREP(IDPF_RX_BI_BUFID_M, buf_id) |
> (!!(test_bit(__IDPF_Q_GEN_CHK, refillq->flags)) <<
>IDPF_RX_BI_GEN_S);
Why isn't that one converted as well?
>
> @@ -1825,14 +1825,14 @@ static bool idpf_tx_clean_complq(struct idpf_queue
> *complq, int budget,
> u16 gen;
>
> /* if the descriptor isn't done, no work yet to do */
> - gen = (le16_to_cpu(tx_desc->qid_comptype_gen) &
> - IDPF_TXD_COMPLQ_GEN_M) >> IDPF_TXD_COMPLQ_GEN_S;
> + gen = FIELD_GET(IDPF_TXD_COMPLQ_GEN_M,
> + le16_to_cpu(tx_desc->qid_comptype_gen));
The definition:
#define IDPF_TXD_COMPLQ_GEN_M BIT_ULL(IDPF_TXD_COMPLQ_GEN_S)
Please don't use FIELD_*() API for 1 bit.
gen = !!(le16_to_cpu(tx_desc->qid_comptype_gen) &
IDPF_TXD_COMPLQ_GEN_M);
is enough.
Moreover, you could use le*_{get,encode,replace}_bits() to get/set LE
values right away without 2-step operation (from/to CPU + masks), but
you didn't do that here (see below for an example).
> if (test_bit(__IDPF_Q_GEN_CHK, complq->flags) != gen)
> break;
>
> /* Find necessary info of TX queue to clean buffers */
> - rel_tx_qid = (le16_to_cpu(tx_desc->qid_comptype_gen) &
> - IDPF_TXD_COMPLQ_QID_M) >> IDPF_TXD_COMPLQ_QID_S;
> + rel_tx_qid = FIELD_GET(IDPF_TXD_COMPLQ_QID_M,
> +le16_to_cpu(tx_desc->qid_comptype_gen));
rel_tx_qid = le16_get_bits(tx_desc->qid_comptype_gen,
IDPF_TXD_COMPLQ_QID_M);
> if (rel_tx_qid >= complq->txq_grp->num_txq ||
> !complq->txq_grp->txqs[rel_tx_qid]) {
> dev_err(&complq->vport->adapter->pdev->dev,
> @@ -1842,9 +1842,8 @@ static bool idpf_tx_clean_complq(struct idpf_queue
> *complq, int budget,
> tx_q = complq->txq_grp->txqs[rel_tx_qid];
>
> /* Determine completion type */
> - ctype = (le16_to_cpu(tx_desc->qid_comptype_gen) &
> - IDPF_TXD_COMPLQ_COMPL_TYPE_M) >>
> - IDPF_TXD_COMPLQ_COMPL_TYPE_S;
> + ctype = FIELD_GET(IDPF_TXD_COMPLQ_COMPL_TYPE_M,
> + le16_to_cpu(tx_desc->qid_comptype_gen));
Same.
> switch (ctype) {
> case IDPF_TXD_COMPLT_RE:
> hw_head = le16_to_cpu(tx_desc->q_head_compl_tag.q_head);
> @@ -1947,8 +1946,7 @@ void idpf_tx_splitq_build_ctb(union idpf_tx_flex_desc
> *desc,
> desc->q.qw1.cmd_dtype =
> cpu_to_le16(params->dtype & IDPF_FLEX_TXD_QW1_DTYPE_M);
>
[Intel-wired-lan] [PATCH iwl] idpf: fix corrupted frames and skb leaks in singleq mode
idpf_ring::skb serves only for keeping an incomplete frame between
several NAPI Rx polling cycles, as one cycle may end up before
processing the end of packet descriptor. The pointer is taken from
the ring onto the stack before entering the loop and gets written
there after the loop exits. When inside the loop, only the onstack
pointer is used.
For some reason, the logics is broken in the singleq mode, where the
pointer is taken from the ring each iteration. This means that if a
frame got fragmented into several descriptors, each fragment will have
its own skb, but only the last one will be passed up the stack
(containing garbage), leaving the rest leaked.
Just don't touch the ring skb field inside the polling loop, letting
the onstack skb pointer work as expected: build a new skb if it's the
first frame descriptor and attach a frag otherwise.
Fixes: a5ab9ee0df0b ("idpf: add singleq start_xmit and napi poll")
Reviewed-by: Przemek Kitszel
Reviewed-by: Michal Kubiak
Signed-off-by: Alexander Lobakin
---
drivers/net/ethernet/intel/idpf/idpf_singleq_txrx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/idpf/idpf_singleq_txrx.c
b/drivers/net/ethernet/intel/idpf/idpf_singleq_txrx.c
index 81288a17da2a..20c4b3a64710 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_singleq_txrx.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_singleq_txrx.c
@@ -1044,7 +1044,6 @@ static int idpf_rx_singleq_clean(struct idpf_queue *rx_q,
int budget)
}
idpf_rx_sync_for_cpu(rx_buf, fields.size);
- skb = rx_q->skb;
if (skb)
idpf_rx_add_frag(rx_buf, skb, fields.size);
else
--
2.43.0
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] [EXT] [PATCH iwl-net v2 1/2] igc: Report VLAN EtherType matching back to user
Hi Kurt,
>+ if (rule->filter.match_flags & IGC_FILTER_FLAG_VLAN_ETYPE) {
>+ fsp->flow_type |= FLOW_EXT;
>+ fsp->h_ext.vlan_etype = rule->filter.vlan_etype;
>+ fsp->m_ext.vlan_etype = ETHER_TYPE_FULL_MASK;
[Suman] User can provide mask for vlan-etype as well. Why not take that rather
than hard coding it? I checked you are already doing the same for TCI in the
other patch.
>+ }
>+
> if (rule->filter.match_flags & IGC_FILTER_FLAG_VLAN_TCI) {
> fsp->flow_type |= FLOW_EXT;
> fsp->h_ext.vlan_tci = htons(rule->filter.vlan_tci);
>--
>2.39.2
>
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
[Intel-wired-lan] [tnguy-net-queue:main] BUILD SUCCESS 777f245eec8152926b411e3d4f4545310f52cbed
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git main branch HEAD: 777f245eec8152926b411e3d4f4545310f52cbed Merge branch 'net-ravb-fixes-for-the-ravb-driver' elapsed time: 1830m configs tested: 285 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alphaallyesconfig gcc alpha defconfig gcc arc allmodconfig gcc arc allnoconfig gcc arc allyesconfig gcc arc defconfig gcc archsdk_defconfig gcc arc randconfig-001-20231130 gcc arc randconfig-001-20231201 gcc arc randconfig-002-20231130 gcc arc randconfig-002-20231201 gcc arc tb10x_defconfig gcc arcvdk_hs38_defconfig gcc arm allmodconfig gcc arm allnoconfig gcc arm allyesconfig gcc arm defconfig clang arm exynos_defconfig gcc arm lpc32xx_defconfig clang armmulti_v5_defconfig clang arm randconfig-001-20231130 gcc arm randconfig-001-20231201 gcc arm randconfig-002-20231130 gcc arm randconfig-002-20231201 gcc arm randconfig-003-20231130 gcc arm randconfig-003-20231201 gcc arm randconfig-004-20231130 gcc arm randconfig-004-20231201 gcc armspear6xx_defconfig gcc arm64allmodconfig clang arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-001-20231130 gcc arm64 randconfig-001-20231201 gcc arm64 randconfig-002-20231130 gcc arm64 randconfig-002-20231201 gcc arm64 randconfig-003-20231130 gcc arm64 randconfig-003-20231201 gcc arm64 randconfig-004-20231130 gcc arm64 randconfig-004-20231201 gcc csky allmodconfig gcc csky allnoconfig gcc csky allyesconfig gcc cskydefconfig gcc csky randconfig-001-20231130 gcc csky randconfig-001-20231201 gcc csky randconfig-002-20231130 gcc csky randconfig-002-20231201 gcc hexagon allmodconfig clang hexagon allnoconfig clang hexagon allyesconfig clang hexagon defconfig clang hexagon randconfig-001-20231201 clang hexagon randconfig-002-20231201 clang i386 allmodconfig clang i386 allnoconfig clang i386 allyesconfig clang i386 buildonly-randconfig-001-20231201 gcc i386 buildonly-randconfig-002-20231201 gcc i386 buildonly-randconfig-003-20231201 gcc i386 buildonly-randconfig-004-20231201 gcc i386 buildonly-randconfig-005-20231201 gcc i386 buildonly-randconfig-006-20231201 gcc i386defconfig gcc i386 randconfig-001-20231201 gcc i386 randconfig-002-20231201 gcc i386 randconfig-003-20231201 gcc i386 randconfig-004-20231201 gcc i386 randconfig-005-20231201 gcc i386 randconfig-006-20231201 gcc i386 randconfig-011-20231130 clang i386 randconfig-011-20231201 clang i386 randconfig-012-20231130 clang i386 randconfig-012-20231201 clang i386 randconfig-013-20231130 clang i386 randconfig-013-20231201 clang i386 randconfig-014-20231130 clang i386 randconfig-014-20231201 clang i386 randconfig-015-20231130 clang i386 randconfig-015-20231201 clang i386 randconfig-016-20231130 clang i386 randconfig-016-20231201 clang loongarchalldefconfig gcc loongarchallmodconfig gcc
[Intel-wired-lan] [tnguy-next-queue:main] BUILD SUCCESS 7e0222686316f5506e51182f02c1d83ecc34c471
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git main branch HEAD: 7e0222686316f5506e51182f02c1d83ecc34c471 Merge branch 'net-ethernet-convert-to-platform-remove-callback-returning-void' elapsed time: 1686m configs tested: 201 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alpha defconfig gcc arc allnoconfig gcc arc defconfig gcc archsdk_defconfig gcc arc randconfig-001-20231201 gcc arc randconfig-002-20231201 gcc arc tb10x_defconfig gcc arcvdk_hs38_defconfig gcc arm allnoconfig gcc arm defconfig clang arm mv78xx0_defconfig clang armneponset_defconfig clang arm randconfig-001-20231201 gcc arm randconfig-002-20231201 gcc arm randconfig-003-20231201 gcc arm randconfig-004-20231201 gcc armspear6xx_defconfig gcc arm64allmodconfig clang arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-001-20231201 gcc arm64 randconfig-002-20231201 gcc arm64 randconfig-003-20231201 gcc arm64 randconfig-004-20231201 gcc csky allnoconfig gcc cskydefconfig gcc csky randconfig-001-20231201 gcc csky randconfig-002-20231201 gcc hexagon allmodconfig clang hexagon allnoconfig clang hexagon allyesconfig clang hexagon defconfig clang hexagon randconfig-001-20231201 clang hexagon randconfig-002-20231201 clang i386 allmodconfig clang i386 allnoconfig clang i386 allyesconfig clang i386 buildonly-randconfig-001-20231201 gcc i386 buildonly-randconfig-002-20231201 gcc i386 buildonly-randconfig-003-20231201 gcc i386 buildonly-randconfig-004-20231201 gcc i386 buildonly-randconfig-005-20231201 gcc i386 buildonly-randconfig-006-20231201 gcc i386defconfig gcc i386 randconfig-001-20231201 gcc i386 randconfig-002-20231201 gcc i386 randconfig-003-20231201 gcc i386 randconfig-004-20231201 gcc i386 randconfig-005-20231201 gcc i386 randconfig-006-20231201 gcc i386 randconfig-011-20231201 clang i386 randconfig-012-20231201 clang i386 randconfig-013-20231201 clang i386 randconfig-014-20231201 clang i386 randconfig-015-20231201 clang i386 randconfig-016-20231201 clang loongarchallmodconfig gcc loongarch allnoconfig gcc loongarchallyesconfig gcc loongarch defconfig gcc loongarch loongson3_defconfig gcc loongarch randconfig-001-20231201 gcc loongarch randconfig-002-20231201 gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k allyesconfig gcc m68kdefconfig gcc m68k hp300_defconfig gcc m68k virt_defconfig gcc microblaze allmodconfig gcc microblazeallnoconfig gcc microblaze allyesconfig gcc microblaze defconfig gcc mips allmodconfig gcc mips allnoconfig clang mips allyesconfig gcc mips db1xxx_defconfig gcc mips fuloong2e_defconfig gcc mipsgpr_defconfig gcc mips loongson1b_defconfig gcc mips rb532_defconfig gcc nios2allmodconfig gcc nios2 allnoconfig gcc nios2allyesco
Re: [Intel-wired-lan] [PATCH iwl-next v1] idpf: refactor some missing field get/prep conversions
On 12/1/2023 6:32 AM, Alexander Lobakin wrote:
> From: Jesse Brandeburg
>> --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
>> +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
>> @@ -505,7 +505,7 @@ static void idpf_rx_post_buf_refill(struct idpf_sw_queue
>> *refillq, u16 buf_id)
>>
>> /* store the buffer ID and the SW maintained GEN bit to the refillq */
>> refillq->ring[nta] =
>> -((buf_id << IDPF_RX_BI_BUFID_S) & IDPF_RX_BI_BUFID_M) |
>> +FIELD_PREP(IDPF_RX_BI_BUFID_M, buf_id) |
>> (!!(test_bit(__IDPF_Q_GEN_CHK, refillq->flags)) <<
>> IDPF_RX_BI_GEN_S);
>
> Why isn't that one converted as well?
Because it's not a constant, and it's not checking a mask with "&", so
the automation ignored it. I *did* a test, and we could convert the
return value from test_bit (a bool) into the IDPF_RX_BI_GEN_M mask with
FIELD_PREP, since C-code allows the luxury of converting a bool to a
"1", even though it's a bit type ugly in this age of strict typing.
>
>>
>> @@ -1825,14 +1825,14 @@ static bool idpf_tx_clean_complq(struct idpf_queue
>> *complq, int budget,
>> u16 gen;
>>
>> /* if the descriptor isn't done, no work yet to do */
>> -gen = (le16_to_cpu(tx_desc->qid_comptype_gen) &
>> - IDPF_TXD_COMPLQ_GEN_M) >> IDPF_TXD_COMPLQ_GEN_S;
>> +gen = FIELD_GET(IDPF_TXD_COMPLQ_GEN_M,
>> +le16_to_cpu(tx_desc->qid_comptype_gen));
>
> The definition:
>
> #define IDPF_TXD_COMPLQ_GEN_M BIT_ULL(IDPF_TXD_COMPLQ_GEN_S)
>
> Please don't use FIELD_*() API for 1 bit.
Did you mean that gen is effectively used as a bool? I think that has
nothing to do with my change over to FIELD_GET, but I could see how
redesigning this code would be useful, but not as part of this
conversion series.
>
> gen = !!(le16_to_cpu(tx_desc->qid_comptype_gen) &
>IDPF_TXD_COMPLQ_GEN_M);
>
> is enough.
Generally I'd prefer that the kind of check above returned a bool with a
constant conversion of the mask (compile time) to an LE16 mask, and then
use that, which is why all of our other drivers do that instead.
>
> Moreover, you could use le*_{get,encode,replace}_bits() to get/set LE
> values right away without 2-step operation (from/to CPU + masks), but
> you didn't do that here (see below for an example).
Those aren't widely used yet in our drivers so I wasn't picking them up
yet. But thank you for pointing that out.
> In general, I would say those two issues are very common in IDPF and
> also the whole your series converting the Intel drivers. The scripts
> won't check whether the mask has only 1 bit or whether the value gets
> converted from/to LE, so they won't help here.
I had been hoping to do some more followup work. it's possible that with
some tweaking the coccinelle script could learn how to detect non-pow2
constants, and therefore possibly one bit constants as well. Maybe
@Julia can help us refine the script and possibly get it into the
scripts/coccinelle directory to help other drivers as well.
> Could you maybe manually recheck all the places where bitfield masks are
> used at least in IDPF (better in ice, iavf, i40e, ..., as well) and
> posted a series that would address them? At the end, manual work is more
> valuable than automated conversions :p
I think a followup series would work better for this, do you agree?
Thanks,
Jesse
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] [PATCH iwl-next v1] idpf: refactor some missing field get/prep conversions
On Fri, 1 Dec 2023, Jesse Brandeburg wrote:
> On 12/1/2023 6:32 AM, Alexander Lobakin wrote:
> > From: Jesse Brandeburg
>
> >> --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> >> +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> >> @@ -505,7 +505,7 @@ static void idpf_rx_post_buf_refill(struct
> >> idpf_sw_queue *refillq, u16 buf_id)
> >>
> >>/* store the buffer ID and the SW maintained GEN bit to the refillq */
> >>refillq->ring[nta] =
> >> - ((buf_id << IDPF_RX_BI_BUFID_S) & IDPF_RX_BI_BUFID_M) |
> >> + FIELD_PREP(IDPF_RX_BI_BUFID_M, buf_id) |
> >>(!!(test_bit(__IDPF_Q_GEN_CHK, refillq->flags)) <<
> >> IDPF_RX_BI_GEN_S);
> >
> > Why isn't that one converted as well?
>
> Because it's not a constant, and it's not checking a mask with "&", so
> the automation ignored it. I *did* a test, and we could convert the
> return value from test_bit (a bool) into the IDPF_RX_BI_GEN_M mask with
> FIELD_PREP, since C-code allows the luxury of converting a bool to a
> "1", even though it's a bit type ugly in this age of strict typing.
>
> >
> >>
> >> @@ -1825,14 +1825,14 @@ static bool idpf_tx_clean_complq(struct idpf_queue
> >> *complq, int budget,
> >>u16 gen;
> >>
> >>/* if the descriptor isn't done, no work yet to do */
> >> - gen = (le16_to_cpu(tx_desc->qid_comptype_gen) &
> >> -IDPF_TXD_COMPLQ_GEN_M) >> IDPF_TXD_COMPLQ_GEN_S;
> >> + gen = FIELD_GET(IDPF_TXD_COMPLQ_GEN_M,
> >> + le16_to_cpu(tx_desc->qid_comptype_gen));
> >
> > The definition:
> >
> > #define IDPF_TXD_COMPLQ_GEN_M BIT_ULL(IDPF_TXD_COMPLQ_GEN_S)
> >
> > Please don't use FIELD_*() API for 1 bit.
>
> Did you mean that gen is effectively used as a bool? I think that has
> nothing to do with my change over to FIELD_GET, but I could see how
> redesigning this code would be useful, but not as part of this
> conversion series.
>
> >
> > gen = !!(le16_to_cpu(tx_desc->qid_comptype_gen) &
> > IDPF_TXD_COMPLQ_GEN_M);
> >
> > is enough.
>
> Generally I'd prefer that the kind of check above returned a bool with a
> constant conversion of the mask (compile time) to an LE16 mask, and then
> use that, which is why all of our other drivers do that instead.
>
> >
> > Moreover, you could use le*_{get,encode,replace}_bits() to get/set LE
> > values right away without 2-step operation (from/to CPU + masks), but
> > you didn't do that here (see below for an example).
>
> Those aren't widely used yet in our drivers so I wasn't picking them up
> yet. But thank you for pointing that out.
>
>
>
>
> > In general, I would say those two issues are very common in IDPF and
> > also the whole your series converting the Intel drivers. The scripts
> > won't check whether the mask has only 1 bit or whether the value gets
> > converted from/to LE, so they won't help here.
>
> I had been hoping to do some more followup work. it's possible that with
> some tweaking the coccinelle script could learn how to detect non-pow2
> constants, and therefore possibly one bit constants as well. Maybe
> @Julia can help us refine the script and possibly get it into the
> scripts/coccinelle directory to help other drivers as well.
I don't have the original script handy.
If it is an explicit constant, like 8, then you can match it with
something like:
constant pow2 : script:python() { is_pow2(pow2) };
where is_pow2 is a python function that first converts pow2 to an integer,
and then, if that succeeds, checks if it is a power of two. The result of
is_pow2 should be true or false.
When there is a #define constant, then you can to match the #define to
determine the value. This may require options like --all-includes or
--recursive-includes.
Then you can write:
@r@
constant pow2 : script:python() { is_pow2(pow2) };
identifier i;
@@
#define i pow2
and then in some later rule, you can have
identifier r.i;
and then use i in a place where you expect a power of two constant.
julia
>
> > Could you maybe manually recheck all the places where bitfield masks are
> > used at least in IDPF (better in ice, iavf, i40e, ..., as well) and
> > posted a series that would address them? At the end, manual work is more
> > valuable than automated conversions :p
>
> I think a followup series would work better for this, do you agree?
>
> Thanks,
> Jesse
>
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
[Intel-wired-lan] [PATCH iwl-next v1] ice: Add support for devlink loopback param.
Add support for devlink loopback param. Supported values are "enabled",
"disabled" and "prioritized". Default configuration is set to "enabled.
By default loopback traffic BW is locked to PF configured BW. HW is
capable of higher speeds on loopback traffic. Loopback param set to
"prioritized" enables HW BW prioritization for VF to VF traffic,
effectively increasing BW between VFs. Applicable to 8x10G and 4x25G
cards.
To achieve max loopback BW one could:
- Make, as much as possible, fair distribution of loopback usages
between groups to gain maximal loopback BW.
- Try to dedicate ports for loopback only traffic, with minimal network
traffic.
Changing loopback configuration will trigger CORER reset in order to take
effect.
Example command to change current value:
devlink dev param set pci/:b2:00.3 name loopback value prioritized \
cmode permanent
Co-developed-by: Michal Wilczynski
Signed-off-by: Michal Wilczynski
Reviewed-by: Przemek Kitszel
Signed-off-by: Pawel Kaminski
---
.../net/ethernet/intel/ice/ice_adminq_cmd.h | 11 +-
drivers/net/ethernet/intel/ice/ice_common.c | 6 +-
drivers/net/ethernet/intel/ice/ice_devlink.c | 128 +-
drivers/net/ethernet/intel/ice/ice_type.h | 1 +
4 files changed, 143 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
index 6a5e974a1776..13d0e3cbc24c 100644
--- a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
+++ b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
@@ -230,6 +230,13 @@ struct ice_aqc_get_sw_cfg_resp_elem {
#define ICE_AQC_GET_SW_CONF_RESP_IS_VF BIT(15)
};
+/* Loopback port parameter mode values. */
+enum ice_loopback_mode {
+ ICE_LOOPBACK_MODE_ENABLED = 0,
+ ICE_LOOPBACK_MODE_DISABLED = 1,
+ ICE_LOOPBACK_MODE_PRIORITIZED = 2,
+};
+
/* Set Port parameters, (direct, 0x0203) */
struct ice_aqc_set_port_params {
__le16 cmd_flags;
@@ -238,7 +245,9 @@ struct ice_aqc_set_port_params {
__le16 swid;
#define ICE_AQC_PORT_SWID_VALIDBIT(15)
#define ICE_AQC_PORT_SWID_M0xFF
- u8 reserved[10];
+ u8 loopback_mode;
+#define ICE_AQC_SET_P_PARAMS_LOOPBACK_MODE_VALID BIT(2)
+ u8 reserved[9];
};
/* These resource type defines are used for all switch resource
diff --git a/drivers/net/ethernet/intel/ice/ice_common.c
b/drivers/net/ethernet/intel/ice/ice_common.c
index 2f67ea1feb60..2efa781efcdb 100644
--- a/drivers/net/ethernet/intel/ice/ice_common.c
+++ b/drivers/net/ethernet/intel/ice/ice_common.c
@@ -1019,7 +1019,7 @@ int ice_init_hw(struct ice_hw *hw)
status = -ENOMEM;
goto err_unroll_cqinit;
}
-
+ hw->port_info->loopback_mode = ICE_LOOPBACK_MODE_ENABLED;
/* set the back pointer to HW */
hw->port_info->hw = hw;
@@ -2962,6 +2962,10 @@ ice_aq_set_port_params(struct ice_port_info *pi, bool
double_vlan,
cmd = &desc.params.set_port_params;
ice_fill_dflt_direct_cmd_desc(&desc, ice_aqc_opc_set_port_params);
+
+ cmd->loopback_mode = pi->loopback_mode |
+ ICE_AQC_SET_P_PARAMS_LOOPBACK_MODE_VALID;
+
if (double_vlan)
cmd_flags |= ICE_AQC_SET_P_PARAMS_DOUBLE_VLAN_ENA;
cmd->cmd_flags = cpu_to_le16(cmd_flags);
diff --git a/drivers/net/ethernet/intel/ice/ice_devlink.c
b/drivers/net/ethernet/intel/ice/ice_devlink.c
index 65be56f2af9e..8fe5bda5d5fe 100644
--- a/drivers/net/ethernet/intel/ice/ice_devlink.c
+++ b/drivers/net/ethernet/intel/ice/ice_devlink.c
@@ -1429,6 +1429,127 @@ ice_devlink_enable_iw_validate(struct devlink *devlink,
u32 id,
return 0;
}
+#define DEVLINK_LPBK_DISABLED_STR "disabled"
+#define DEVLINK_LPBK_ENABLED_STR "enabled"
+#define DEVLINK_LPBK_PRIORITIZED_STR "prioritized"
+
+/**
+ * ice_devlink_loopback_mode_to_str - Get string for lpbk mode.
+ * @mode: Loopback_mode used in port_info struct.
+ *
+ * Return: Mode respective string or "Invalid".
+ */
+static const char *ice_devlink_loopback_mode_to_str(enum ice_loopback_mode
mode)
+{
+ switch (mode) {
+ case ICE_LOOPBACK_MODE_ENABLED:
+ return DEVLINK_LPBK_ENABLED_STR;
+ case ICE_LOOPBACK_MODE_PRIORITIZED:
+ return DEVLINK_LPBK_PRIORITIZED_STR;
+ case ICE_LOOPBACK_MODE_DISABLED:
+ return DEVLINK_LPBK_DISABLED_STR;
+ }
+
+ return "Invalid";
+}
+
+/**
+ * ice_devlink_loopback_str_to_mode - Get lpbk mode from string name.
+ * @mode_str: Loopback mode string.
+ *
+ * Return: Mode value or negative number if invalid.
+ */
+static int ice_devlink_loopback_str_to_mode(const char *mode_str)
+{
+ if (!strcmp(mode_str, DEVLINK_LPBK_ENABLED_STR))
+ return ICE_LOOPBACK_MODE_ENABLED;
+ else if (!strcmp(mode_str, DEVLINK_LPBK_PRIORITIZED_STR))
+ return ICE_LOOPBACK_MODE_PRIORITIZED;
+ else if (
Re: [Intel-wired-lan] Compile of out-of-tree 'ice' driver fails on 32 bit
On 12/1/2023 5:41 AM, tedheadster wrote:
>>> Has anyone tried compiling the out-of-tree kernel network software
>>> for the 'ice' driver on 32 bit i386? I tried it for the
>>> long-term-support 5.10.197 kernel and got these compile time errors:
>>
>> Are those regressions?
>> Have you tried 1.12.x?
>> We will also soon release also 1.13.x
>
> I just tried 1.11.14, 1.11.17.1, and 1.12.7. They all had similar
> compile failures.
I've got a quick patch for Matthew, I'll send it to him off list for
some testing.
I'm not super excited about some of the warning fixes as fixing 32 bit
to get rid of printk formatting warnings introduces 64 bit warnings :-(
>
> > $ make ARCH=i386 CFLAGS_EXTRA="-DGNSS_SUPPORT"
>>> make ccflags-y="-DGNSS_SUPPORT -DUSE_INTEL_AUX_BUS" -C
>>> "/lib/modules/5.10.197.i686-pentium4-mpentium4-lenovo/source"
>>> CONFIG_ICE=m CONFIG_MODULE_SIG=n CONFIG_MODULE_SIG_ALL=
>>> M="/tmp/ice-1.11.14/src" NEED_AUX_BUS="2" modules
>>>CC [M] /tmp/ice-1.11.14/src/ice_main.o
>>> In file included from /tmp/ice-1.11.14/src/kcompat.h:3351,
>>> from /tmp/ice-1.11.14/src/ice.h:7,
>>> from /tmp/ice-1.11.14/src/ice_main.c:8:
>>> /tmp/ice-1.11.14/src/kcompat_impl.h:851:20: error: redefinition of
>>> ‘eth_hw_addr_set’
>>>851 | static inline void eth_hw_addr_set(struct net_device *dev,
>>> const u8 *addr)
>>>|^~~
>>> In file included from /tmp/ice-1.11.14/src/kcompat.h:16:
>>> ./include/linux/etherdevice.h:309:20: note: previous definition of
>>> ‘eth_hw_addr_set’ with type ‘void(struct net_device *, const u8 *)’
>>> {aka ‘void(struct net_device *, const unsigned char *)’}
>>>309 | static inline void eth_hw_addr_set(struct net_device *dev,
>>> const u8 *addr)
The compat fix for eth_hw_addr_set is just put #if 0 around it. Looks
like ubuntu backported something and picked up a conflict.
The newer kcompat-generator script in 1.12.x and newer should help that
issue, or at least *could* if it's not already fixed.
>>
>> That particular thing could be rather easily solved,
>> for official fix, 1.14 would be the earliest, but let me know how it
>> works with 1.12.x so I could prepare some patch for you.
>>
>>>|^~~
>>> In file included from ./include/linux/bits.h:6,
>>> from ./include/linux/bitops.h:5,
>>> from ./include/linux/kernel.h:12,
>>> from ./include/asm-generic/bug.h:20,
>>> from ./arch/x86/include/asm/bug.h:93,
>>> from ./include/linux/bug.h:5,
>>> from ./include/linux/io.h:11,
>>> from /tmp/ice-1.11.14/src/kcompat.h:13:
>>> /tmp/ice-1.11.14/src/ice_main.c: In function ‘ice_pf_fwlog_is_input_valid’:
>>> ./include/vdso/bits.h:7:40: warning: left shift count >= width of type
>>> [-Wshift-count-overflow]
>>> 7 | #define BIT(nr) (UL(1) << (nr))
>>>|^~
>>> /tmp/ice-1.11.14/src/ice_main.c:5992:23: note: in expansion of macro ‘BIT’
>>> 5992 | if (events >= BIT(ICE_AQC_FW_LOG_ID_MAX)) {
>>>| ^~~
>>> ./include/vdso/bits.h:7:40: warning: left shift count >= width of type
>>> [-Wshift-count-overflow]
>>> 7 | #define BIT(nr) (UL(1) << (nr))
>>>|^~
>>> ./include/linux/dev_printk.h:112:39: note: in expansion of macro ‘BIT’
>>>112 | _dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
>>>| ^~~
>>> /tmp/ice-1.11.14/src/ice_main.c:5993:17: note: in expansion of macro
>>> ‘dev_err’
>>> 5993 | dev_err(ice_pf_to_dev(pf), "Invalid FW log
>>> events 0x%lx, all FW log event bits >= 0x%lx are invalid\n",
The fix here is to make the print code use BIT_ULL(ICE_AQC_FW_LOG_ID_MAX)
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] [PATCH iwl-next v1] ice: Add support for devlink loopback param.
On Fri, 1 Dec 2023 15:59:49 -0800 Pawel Kaminski wrote: > Add support for devlink loopback param. Supported values are "enabled", > "disabled" and "prioritized". Default configuration is set to "enabled. > > By default loopback traffic BW is locked to PF configured BW. First off - hairpin-bandwidth or some such would be a much better name. Second - you must explain every devlink param in Documentation/ Also admission ctrl vs prioritizing sounds like different knobs. > HW is > capable of higher speeds on loopback traffic. Loopback param set to > "prioritized" enables HW BW prioritization for VF to VF traffic, > effectively increasing BW between VFs. Applicable to 8x10G and 4x25G > cards. Not very clear what this means... So the VFs are Tx bandwidth limited to link speed. How does the device know it can admit extra traffic? Presumably this doesn't affect rates set by devlink rate? > To achieve max loopback BW one could: > - Make, as much as possible, fair distribution of loopback usages >between groups to gain maximal loopback BW. Can't parse what this means. > - Try to dedicate ports for loopback only traffic, with minimal network >traffic. Or this. > Changing loopback configuration will trigger CORER reset in order to take > effect. Changing config of a permanent param shouldn't trigger anything. Please see the documentation for expected behavior.. ___ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
