On Wed, 30 Jul 2025 11:31:35 +0200 Krzysztof Kozlowski wrote:
> I pop up there a lot, but there is no confusion. I am (and maybe we are
> all?) well aware that checkpatch hard limit is 100 as explained also here:
> https://lore.kernel.org/all/df2e466a-cdaa-4263-ae16-7bf56c0ed...@kernel.org/
>
> Bu
On Fri, 25 Jul 2025 15:00:46 -0400 Steven Rostedt wrote:
> On Fri, 25 Jul 2025 11:41:14 -0700
> Jakub Kicinski wrote:
> > On Fri, 25 Jul 2025 13:53:56 -0400 Sasha Levin wrote:
> > > Co-developed-by: Claude claude-opus-4-20250514
> > > ---
> >
On Fri, 25 Jul 2025 13:53:56 -0400 Sasha Levin wrote:
> Co-developed-by: Claude claude-opus-4-20250514
> ---
>Documentation/power/opp.rst | 2 +-
>1 file changed, 1 insertion(+), 1 deletion(-)
I think we should suggest that the tag is under --- ?
It's only relevant durin
On Fri, 25 Jul 2025 10:20:19 -0700 Jakub Kicinski wrote:
> Reproducer: test.case.path # 001122aabb (optimal) commit of the test case
s/optimal/optional/
On Fri, 25 Jul 2025 09:38:28 -0700 dan.j.willi...@intel.com wrote:
> Jakub Kicinski wrote:
> > Hi!
> >
> > Does anyone have ideas about crediting test authors or tests for bugs
> > discovered? We increasingly see situations where someone adds a test
> > then ou
On Fri, 25 Jul 2025 17:39:12 +0100 Mark Brown wrote:
> On Fri, Jul 25, 2025 at 08:00:23AM -0700, Jakub Kicinski wrote:
>
> > Does anyone have ideas about crediting test authors or tests for bugs
> > discovered? We increasingly see situations where someone adds a test
> &g
Hi!
Does anyone have ideas about crediting test authors or tests for bugs
discovered? We increasingly see situations where someone adds a test
then our subsystem CI uncovers a (1 in a 100 runs) bug using that test.
Using reported-by doesn't feel right. But credit should go to the
person who wrot
On Fri, 25 Jul 2025 02:20:01 + Hangbin Liu wrote:
> On Thu, Jul 24, 2025 at 07:35:01AM -0700, Jakub Kicinski wrote:
> > On Thu, 24 Jul 2025 14:31:43 + Hangbin Liu wrote:
> > > Should I drop this selftest as it needs the new iproute2 feature that has
> > > not
On Fri, 25 Jul 2025 06:28:48 + Hangbin Liu wrote:
> Add a selftest to verify bonding behavior when `lacp_active` is set to `off`.
>
> The test checks the following:
> - The passive LACP bond should not send LACPDUs before receiving a partner's
> LACPDU.
> - The transmitted LACPDUs must not i
On Thu, 24 Jul 2025 14:31:43 + Hangbin Liu wrote:
> Should I drop this selftest as it needs the new iproute2 feature that has
> not applied yet?
No need, I'll add the iproute2 patch in the CI.
On Thu, 10 Jul 2025 15:35:32 + Song, Yoong Siang wrote:
> Would it be advisable to update the documentation to indicate that
> drivers are expected to copy any device-reserved metadata from the
> metadata area? This would ensure that xdp_buff->data_meta is equal
> to xdp_buff->data before a BPF
On Tue, 8 Jul 2025 02:06:11 + Song, Yoong Siang wrote:
>> Why would the driver need to move it back?
>> On XDP_PASS an skb is constructed, so the metadata should
>> be transferred to the skb. There is no need to copy it back
>> as a prepend.
>
> I said so because I thought need to put back t
On Tue, 8 Jul 2025 01:34:13 + Song, Yoong Siang wrote:
> >For normal XDP my understanding is that its the driver's responsibility
> >to move the "reserved" stuff out of place before presenting the frame to
> >program.
>
> Is it means that driver needs to move out the "reserved" stuff before
On Tue, 1 Jul 2025 12:29:38 +0800 Song Yoong Siang wrote:
> |<---sizeof(xdp_meta)--|
> | |
> struct xdp_meta rx_desc->address
> ^ ^
>
On Wed, 25 Jun 2025 21:30:12 +0300 Mark Bloch wrote:
> Introduce support for specifying relative bandwidth shares between
> traffic classes (TC) in the devlink-rate API. This new option allows
> users to allocate bandwidth across multiple traffic classes in a
> single command.
net/devlink/rate.c:3
On Mon, 16 Jun 2025 10:08:34 -0700 Gustavo Luiz Duarte wrote:
> This patch series introduces a new feature to netconsole which allows
> appending a message ID to the userdata dictionary.
>
> If the msgid feature is enabled, the message ID is built from a per-target 32
> bit counter that is increme
o a burden when refactoring the code.
Signed-off-by: Jakub Kicinski
---
CC: cor...@lwn.net
CC: workfl...@vger.kernel.org
CC: linux-doc@vger.kernel.org
---
Documentation/process/coding-style.rst | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/process/codi
On Thu, 12 Jun 2025 13:02:16 -0700 Gustavo Luiz Duarte wrote:
> diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
> index 3bf8777fcd01..baa9862c1bc3 100644
> --- a/drivers/net/netconsole.c
> +++ b/drivers/net/netconsole.c
> @@ -155,6 +155,8 @@ struct netconsole_target {
> size_
On Wed, 11 Jun 2025 08:30:11 -0700 Breno Leitao wrote:
> > static int prepare_extradata(struct netconsole_target *nt)
> > {
> > - u32 fields = SYSDATA_CPU_NR | SYSDATA_TASKNAME;
> > + u32 fields = SYSDATA_CPU_NR | SYSDATA_TASKNAME | SYSDATA_MSGID;
>
> This might be gone now, according to y
On Sun, 25 May 2025 17:57:28 +0300 Carolina Jubran wrote:
> >> + -
> >> +name: rate-tc-bw
> >> +type: u32
> >> +doc: |
> >> + Specifies the bandwidth allocation for the Traffic Class as a
> >> + percentage.
> >> +checks:
> >> + m
On Thu, 22 May 2025 00:05:32 +0300 Carolina Jubran wrote:
> On 21/05/2025 1:59, Jakub Kicinski wrote:
> > On Tue, 20 May 2025 21:38:03 +0300 Tariq Toukan wrote:
> >> Test verifies that netdevsim correctly implements devlink ops callbacks
> >> that set tc-bw
On Wed, 21 May 2025 10:05:13 +0300 Tariq Toukan wrote:
> On 21/05/2025 1:59, Jakub Kicinski wrote:
> > On Tue, 20 May 2025 21:38:03 +0300 Tariq Toukan wrote:
> >> Test verifies that netdevsim correctly implements devlink ops callbacks
> >> that set tc-bw
On Tue, 20 May 2025 21:38:03 +0300 Tariq Toukan wrote:
> Test verifies that netdevsim correctly implements devlink ops callbacks
> that set tc-bw on leaf or node rate object.
Please add a test that can actually validate a NIC HW.
The test probably needs to be in Python to use a remote endpoint,
an
A few quick comments here as the test is failing
On Tue, 20 May 2025 21:38:02 +0300 Tariq Toukan wrote:
> + -
> +name: rate-tc-bws
> +type: nest
> +multi-attr: true
> +nested-attributes: dl-rate-tc-bws
> + -
> +name: rate-tc-index
> +type:
On Thu, 15 May 2025 22:19:11 +0800 Luo Jie wrote:
> However, from the patchwork result as below, it seems the dependent
> patch series (for FIELD_MODIFY() macro) did not get picked to validate
> the PPE driver patch series together. This dependency is mentioned in
> the cover letter. Could you advi
On Tue, 13 May 2025 17:58:20 +0800 Luo Jie wrote:
> The PPE (packet process engine) hardware block is available in Qualcomm
> IPQ chipsets that support PPE architecture, such as IPQ9574 and IPQ5332.
> The PPE in the IPQ9574 SoC includes six ethernet ports (6 GMAC and 6
> XGMAC), which are used to c
Functionally LGTM. But I'm not sure if the discussion with Paolo is
resolved, so here's a couple more nit picks:
On Tue, 29 Apr 2025 03:26:40 + Mina Almasry wrote:
> + case SCM_DEVMEM_DMABUF:
> + if (cmsg->cmsg_len != CMSG_LEN(sizeof(u32)))
> + return -EINVA
On Mon, 17 Mar 2025 19:57:59 +0900 Akihiko Odaki wrote:
> +TEST_F(tap, test_vnetbe)
> +{
> + int be = 1;
> + int ret;
> +
> + ASSERT_FALSE(dev_delete(param_dev_tap_name));
> + self->deleted = true;
> +
> + ret = ioctl(self->fd, TUNSETVNETBE, &be);
> + if (ret == -1 && errno
On Mon, 10 Mar 2025 18:00:51 +0800 Lei Yang wrote:
> QE tested this series with virtio-net regression tests, everything works fine.
>
> Tested-by: Lei Yang
It's a bit unclear to me what exactly you tested here
and why you chose this patch set..
If you have a set of automated tests integrating
On Thu, 06 Mar 2025 18:56:33 +0900 Akihiko Odaki wrote:
> Hash reporting
> ==
>
> Allow the guest to reuse the hash value to make receive steering
> consistent between the host and guest, and to save hash computation.
>
> RSS
> ===
>
> RSS is a receive steering algorithm that can be
On Thu, 6 Mar 2025 14:44:41 -0800 Mina Almasry wrote:
> > Meaning it doesn't currently do anything special, or you can't make it
> > do anything special with netdevsim?
>
> Meaning it currently doesn't do anything special with netdevsim. I
> imagine we may be able to create a specialized syzbot ins
On Tue, 4 Mar 2025 17:39:37 -0800 Mina Almasry wrote:
> > > Yes, great idea. I don't see why it wouldn't work.
> > >
> > > We don't expect mixing of net_iovs and pages in the same skb, but
> > > netdevsim could create one net_iov skb every N skbs.
> > >
> > > I guess I'm not totally sure something
On Mon, 3 Mar 2025 19:53:44 -0800 Mina Almasry wrote:
> > Upper devices and BPF access is covered I think, by the skbuff checks.
> > But I think we missed adding a check in validate_xmit_skb() to protect
> > the xmit paths of HW|virt drivers. You can try to add a TC rule which
> > forwards all traf
On Fri, 28 Feb 2025 17:53:24 -0800 Mina Almasry wrote:
> On Fri, Feb 28, 2025 at 4:43 PM Jakub Kicinski wrote:
> > On Thu, 27 Feb 2025 04:12:08 + Mina Almasry wrote:
> > > + if (!skb_frags_readable(skb) && !dev->netmem_tx)
> >
> > H
On Fri, 28 Feb 2025 17:29:13 -0800 Mina Almasry wrote:
> On Fri, Feb 28, 2025 at 4:38 PM Jakub Kicinski wrote:
> > On Thu, 27 Feb 2025 04:12:02 + Mina Almasry wrote:
> > > static inline void __skb_frag_ref(skb_frag_t *frag)
> > > {
> > &g
On Mon, 3 Mar 2025 15:20:33 +0900 Akihiko Odaki wrote:
> > # 5.90 [+0.00] ok 14 tun_vnet_hash.unclassified
> > # 5.90 [+0.00] # RUN tun_vnet_hash.ipv4 ...
> > # 6.18 [+0.28] # tun.c:669:ipv4:Expected 0 (0) !=
> > tun_vnet_hash_check(self->source_fd, self->dest_fds, &packet,
> > sizeof(
On Thu, 27 Feb 2025 04:12:02 + Mina Almasry wrote:
> static inline void __skb_frag_ref(skb_frag_t *frag)
> {
> - get_page(skb_frag_page(frag));
> + get_netmem(skb_frag_netmem(frag));
> }
Silently handling types of memory the caller may not be expecting
always worries me. Why do we n
On Thu, 27 Feb 2025 04:12:08 + Mina Almasry wrote:
> + if (!skb_frags_readable(skb) && !dev->netmem_tx)
How do you know it's for _this_ device tho?
The driver doesn't seem to check the DMA mapping belongs to it either.
Remind me, how do we prevent the unreadable skbs from getting into the
On Fri, 28 Feb 2025 16:58:51 +0900 Akihiko Odaki wrote:
> The added tests confirm tun can perform RSS and hash reporting, and
> reject invalid configurations for them.
The tests may benefit from using FIXTURE_VARIANT(), up to you.
The IPv4 tests fail reliably on a VM with a debug kernel
(kernel/c
launch time is communicated from user space to Ethernet driver via
> launch_time field of struct xsk_tx_metadata.
>
> Suggested-by: Stanislav Fomichev
> Acked-by: Stanislav Fomichev
> Signed-off-by: Song Yoong Siang
Acked-by: Jakub Kicinski
On Sat, 15 Feb 2025 11:01:59 -0800 Jakub Kicinski wrote:
> On Fri, 7 Feb 2025 10:19:39 +0800 Song Yoong Siang wrote:
> > Extend the XDP Tx metadata framework so that user can requests launch time
> > hardware offload, where the Ethernet device will schedule the packet for
> &
launch time is communicated from user space to Ethernet driver via
> launch_time field of struct xsk_tx_metadata.
Acked-by: Jakub Kicinski
On Wed, 5 Feb 2025 11:52:20 -0800 Mina Almasry wrote:
> > please stick to RFC until a driver implementation is ready and
> > included
>
> For the RX path proposals I kept the driver implementation out of the
> series and linked to it in the cover letter. Just to confirm, is that
> OK for this se
On Mon, 3 Feb 2025 22:39:10 + Mina Almasry wrote:
> v3: https://patchwork.kernel.org/project/netdevbpf/list/?series=929401&state=*
> ===
>
> RFC v2:
> https://patchwork.kernel.org/project/netdevbpf/list/?series=920056&state=*
nit: lore links are better
please stick to RFC until a driver im
On Tue, 4 Feb 2025 11:41:09 -0800 Stanislav Fomichev wrote:
> > > Don't we need some way for the device to opt-in (or opt-out) and avoid
> > > such issues?
> > >
> >
> > Yeah, I think likely the driver needs to declare support (i.e. it's
> > not using dma-mapping API with dma-buf addresses).
>
On Tue, 4 Feb 2025 10:05:12 -0800 Randy Dunlap wrote:
> Signed-off-by: John Doe # Company
Interesting :)
On a quick look this seems to be the format of choice for maintainers
who edit patches:
Signed-off-by: Mr Maintainer # fixed xyz
I don't see a single # use in the From lines. I think the #
On Tue, 4 Feb 2025 13:29:18 +0100 Paolo Abeni wrote:
> On 2/3/25 11:39 PM, Mina Almasry wrote:
> > Add support for devmem TX in ncdevmem.
> >
> > This is a combination of the ncdevmem from the devmem TCP series RFCv1
> > which included the TX path, and work by Stan to include the netlink API
> > a
On Tue, 4 Feb 2025 17:49:38 +0200 Laurent Pinchart wrote:
> Or apparently project or customer names for consulting companies:
>
> 29 Kory Maincent (Dent Project)
> 34 Alexis Lothoré (eBPF Foundation)
FWIW these are customer names, indeed. Project/Foundation pays for
contracting work i
On Tue, 4 Feb 2025 08:59:28 +0100 Geert Uytterhoeven wrote:
> You probably also want to document the other popular[*] solution:
>
> From: Patch Author
>
> [*] Statistics for v6.0..v6.14-rc1:
> - "(Company): 3430
> - "+company": 2871
Hm, I mostly associate that format with MAINTA
ommit 2ce67f8bf1ce ("wifi: iwlwifi: mvm: fix iwl_ssid_exist()
check"). Better format would be:
Author: Miri Korenblit (FreeBSD Foundation) <...
Signed-off-by: Jakub Kicinski
---
CC: cor...@lwn.net
CC: workfl...@vger.kernel.org
CC: linux-doc@vger.kernel.org
---
Documentation/process/submitti
On Mon, 27 Jan 2025 19:29:35 +0100 Florian Bezdeka wrote:
> > > Yeah, I don't think we can impose UAPI restrictions on the metadata area
> > > at this point. I guess the best we can do is to educate users that they
> > > should call the timestamp kfunc before they modify the metadata?
> >
> > I
On Fri, 24 Jan 2025 12:45:42 +0100 Toke Høiland-Jørgensen wrote:
> >> I think there is no simple fix for that. That needs some discussion
> >> around the "expectations" to the headroom / meta data area in front of
> >> the actual packet data.
> >
> > By 'simple' you mean without some new UAPI to
On Mon, 20 Jan 2025 09:30:48 -0800 Breno Leitao wrote:
> > > Not sure I followed. The data ({userdata,extradata}_complete) was always
> > > inside nt field, which belongs to target_list.
> >
> > I mean the buffer we use for formatting. Today it's this:
> >
> > static char buf[MAX_PRINT_CHUN
On Fri, 17 Jan 2025 03:02:40 -0800 Breno Leitao wrote:
> > Looks like previously all the data was on the stack, now we have a mix.
>
> Not sure I followed. The data ({userdata,extradata}_complete) was always
> inside nt field, which belongs to target_list.
I mean the buffer we use for formattin
On Wed, 15 Jan 2025 05:35:20 -0800 Breno Leitao wrote:
> + WARN_ON_ONCE(userdata_len + sysdata_len >
> + MAX_EXTRADATA_ENTRY_LEN * MAX_EXTRADATA_ITEMS);
> +
> + /* nt->sysdata_length will be used later to decide if the message
> + * needs to be fragmented.
> + * u
On Wed, 13 Nov 2024 07:10:55 -0800 Breno Leitao wrote:
> + if ! grep -q "cpu=[0-9]\+" "${TMPFILENAME}"; then
> + echo "FAIL: 'cpu=' not found in ${TMPFILENAME}" >&2
> + cat "${TMPFILENAME}" >&2
> + exit "${ksft_fail}"
> + fi
Could we try to do something
Sorry for the late review, I think this will miss v6.13 :(
On Wed, 13 Nov 2024 07:10:53 -0800 Breno Leitao wrote:
> /**
> * struct netconsole_target - Represents a configured netconsole target.
> * @list:Links this target into the target_list.
> @@ -97,6 +105,7 @@ static struct console ne
On Wed, 30 Oct 2024 18:23:26 -0600 Caleb Sander Mateos wrote:
> In a heavy TCP workload, mlx5e_handle_rx_dim() consumes 3% of CPU time,
> 94% of which is attributed to the first push instruction to copy
> dim_sample on the stack for the call to net_dim():
Change itself looks fine, so we can apply,
On Wed, 30 Oct 2024 13:49:08 -0600 Caleb Sander Mateos wrote:
> net_dim() is currently passed a struct dim_sample argument by value.
> struct dim_sample is 24 bytes. Since this is greater 16 bytes, x86-64
> passes it on the stack. All callers have already initialized dim_sample
> on the stack, so p
On Mon, 7 Oct 2024 17:15:01 +0100 Simon Horman wrote:
> > > We could merge or otherwise rearrange that section with the one proposed
> > > by
> > > this patch. But I didn't feel it was necessary last week.
> >
> > Somewhat, we don't push back on correct use of device-managed APIs.
> > But conve
On Mon, 7 Oct 2024 16:55:21 +0100 Simon Horman wrote:
> > > +Netdev discourages patches which perform simple clean-ups, which are not
> > > in
> > > +the context of other work. For example addressing ``checkpatch.pl``
> > > +warnings, or :ref:`local variable ordering` issues. This is because
> >
On Fri, 04 Oct 2024 10:49:53 +0100 Simon Horman wrote:
> The purpose of this section is to document what is the current practice
> regarding clean-up patches which address checkpatch warnings and similar
> problems. I feel there is a value in having this documented so others
> can easily refer to i
On Tue, 3 Sep 2024 11:19:25 -0400 Steven Davis wrote:
> In the section "Mailing list participation", the first few
> lines had grammatical errors and overall was not clear.
Not clear in what way?
> I fixed this by adding "The" before "Linux kernel" and
> specifying that the mailing list is for d
ovide guidelines on naming KUnit files did not fall under workflows@
since Documentation/dev-tools/ isn't covered. The patch volume for
dev-tools isn't huge and most of the changes are interesting. Add it.
Link: https://lore.kernel.org/20240720165441.it.320-k...@kernel.org/ # [1]
Signe
ovide guidelines on naming KUnit files did not fall under workflows@
since Documentation/dev-tools/ isn't covered. The patch volume for
dev-tools isn't huge and most of the changes are interesting. Add it.
Link: https://lore.kernel.org/20240720165441.it.320-k...@kernel.org/ # [1]
Signe
s happened.
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Mark Brown
Reviewed-by: Shuah Khan
Signed-off-by: Jakub Kicinski
---
Encouraged by the immediate acks from notable folks I'm submitting
again, although I'm tempted to resend as part of maintainer-netdev :(
Please do read the r
On Sat, 13 Jul 2024 18:07:25 +0200 Mauro Carvalho Chehab wrote:
> That's basically what I said: such things happen top/down and not at
> developer/maintainer level. Sure having it documented somewhere, on
> some document that management would actually read can be useful on
> discussions, specially
On Sat, 13 Jul 2024 17:26:51 +0300 Laurent Pinchart wrote:
> > +Open development
> > +
> > +
> > +Discussions about user reported issues, and development of new code
> > +should be conducted in a manner typical for the larger subsystem.
> > +It is common for development within a sin
On Fri, 12 Jul 2024 17:00:44 -0700 Dan Williams wrote:
> To be honest I am lost trying to understand who the audience is and what
> the actionable takeaway is from the guidance. It sounds like you are
> trying to educate drive-by submitters to push back against requests to
> take issues off the lis
On Fri, 12 Jul 2024 11:43:14 -0700 Dan Williams wrote:
> This reads as a vague ambiguous quasi-threat with no actionable way to
> enforce it. In contrast, successful maintainers already have a sense of
> the benefits of pushing discussions to the list as much as possible.
>
> For new and growing m
On Fri, 12 Jul 2024 20:11:56 +0200 Mauro Carvalho Chehab wrote:
> Not sure what this somewhat obscure message wants to accomplish.
>
> It is quite common to have developers and maintainers discussing
> outside public forums and internally at the companies they're working
> for. There are lots of
osed to work.
Signed-off-by: Jakub Kicinski
---
CC: workfl...@vger.kernel.org
CC: linux-doc@vger.kernel.org
---
.../maintainer/feature-and-driver-maintainers.rst | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/maintainer/feature-and-driver-maintainers.rst
b
On Tue, 18 Jun 2024 10:56:42 +0800 Heng Qi wrote:
> --- a/Documentation/networking/ethtool-netlink.rst
> +++ b/Documentation/networking/ethtool-netlink.rst
> @@ -1033,6 +1033,8 @@ Kernel response contents:
>``ETHTOOL_A_COALESCE_TX_AGGR_MAX_BYTES`` u32 max aggr size, Tx
>``ETHTOOL_A_
On Tue, 18 Jun 2024 10:56:39 +0800 Heng Qi wrote:
> The NetDIM library provides excellent acceleration for many modern
> network cards. However, the default profiles of DIM limits its maximum
> capabilities for different NICs, so providing a way which the NIC can
> be custom configured is necessary
On Tue, 18 Jun 2024 10:56:42 +0800 Heng Qi wrote:
> + if (dev->irq_moder && dev->irq_moder->profile_flags & DIM_PROFILE_RX) {
> + ret = ethnl_update_profile(dev, &dev->irq_moder->rx_profile,
> +tb[ETHTOOL_A_COALESCE_RX_PROFILE],
> +
On Tue, 14 May 2024 10:08:15 +0800 Heng Qi wrote:
> > We can't make lockdep dependent on NET.
> > People working on other subsystems should be able to use LOCKDEP
> > with minimal builds.
>
> Got it. Then I declare "DIMLIB depends on NET" and clean up other places.
I'm not sure if there's any
On Mon, 13 May 2024 23:39:04 +0800 Heng Qi wrote:
> config PROVE_LOCKING
> bool "Lock debugging: prove locking correctness"
> - depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
> + depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT && NET
We can't make lockdep dependent on NET
On Mon, 13 May 2024 22:52:13 +0800 Heng Qi wrote:
> > > So I think we should declare "CONFIG_PROVE_LOCKING depends on CONFIG_NET".
> > > How do you think?
> >
> > Doesn't sound right, `can we instead make building lib/dim/net_dim.c
>
> Why? IIUC, the reason is that if CONFIG_NET is not set to
On Mon, 13 May 2024 00:36:58 +0800 Heng Qi wrote:
> This failed use case seems to come from this series triggering a problem that
> has not been triggered historically, namely lockdep_rtnl_is_held() is not
> called
> in an environment where CONFIG_NET is not configured and CONFIG_PROVE_LOCKING
>
On Wed, 8 May 2024 21:26:46 +0800 Heng Qi wrote:
> On Tue, 7 May 2024 19:57:52 -0700, Jakub Kicinski wrote:
> > On Sat, 4 May 2024 14:44:45 +0800 Heng Qi wrote:
> > > @@ -1325,6 +1354,8 @@ operations:
> > > - tx-aggr-max-bytes
> > &g
On Sat, 4 May 2024 14:44:43 +0800 Heng Qi wrote:
> The NetDIM library provides excellent acceleration for many modern
> network cards. However, the default profiles of DIM limits its maximum
> capabilities for different NICs, so providing a way which the NIC can
> be custom configured is necessary
On Sat, 4 May 2024 14:44:45 +0800 Heng Qi wrote:
> @@ -1325,6 +1354,8 @@ operations:
> - tx-aggr-max-bytes
> - tx-aggr-max-frames
> - tx-aggr-time-usecs
> +- rx-profile
> +- tx-profile
>dump: *coalesce-get-op
> -
>
On Wed, 8 May 2024 10:12:35 +0800 Heng Qi wrote:
> I would like to confirm if there are still comments on the current version,
> since the current series and the just merged "Remove RTNL lock protection of
> CVQ" conflict with a line of code with the fourth patch, if I can collect
> other comments
On Wed, 1 May 2024 12:45:36 +0800 Heng Qi wrote:
> >net/ethtool/coalesce.c: At top level:
> [...]
> > 446 | static int ethnl_update_profile(struct net_device *dev,
> > |^~~~
> [...]
> > 151 | static int coalesce_put_profile(struct sk_buff
On Tue, 30 Apr 2024 09:59:39 +0800 Heng Qi wrote:
> + if (moder[ETHTOOL_A_IRQ_MODERATION_USEC]) {
> + if (irq_moder->coal_flags & DIM_COALESCE_USEC)
> + new_profile[i].usec =
> + nla_get_u32(moder[ETHTOOL_A_IRQ_MODERATION_USEC]);
> + else
> + retu
On Sun, 28 Apr 2024 22:49:09 +0800 Heng Qi wrote:
> >> +#if IS_ENABLED(CONFIG_DIMLIB)
> >> + if (dev->irq_moder) {
> > This may be NULL
>
>
> Do you mean dev may be null or dev->irq_moder may be null?
> The former has been excluded (see const struct ethtool_ops *ops
>
> = req_info->dev->eth
On Fri, 26 Apr 2024 00:59:46 +0800 Heng Qi wrote:
> The NetDIM library, currently leveraged by an array of NICs, delivers
> excellent acceleration benefits. Nevertheless, NICs vary significantly
> in their dim profile list prerequisites.
>
> Specifically, virtio-net backends may present diverse sw
On Thu, 25 Apr 2024 00:49:26 +0800 Heng Qi wrote:
> If I'm not wrong, you don't want an interface
> like .ndo_init_irq_moder, but instead provide a generic interface in
> dim.c (e.g. net_dim_init_irq_moder() with parameters dev and struct
> dim_irq_moder or separate flags,mode,work). Then this func
On Wed, 24 Apr 2024 21:41:55 +0800 Heng Qi wrote:
> +struct dim_irq_moder {
> + /* See DIM_PROFILE_* */
> + u8 profile_flags;
> +
> + /* See DIM_COALESCE_* for Rx and Tx */
> + u8 coal_flags;
> +
> + /* Rx DIM period count mode: CQE or EQE */
> + u8 dim_rx_mode;
On Wed, 24 Apr 2024 21:10:55 +0800 Heng Qi wrote:
> >> This doesn't work because the first level of sub-nesting of
> >> ETHTOOL_A_COALESCE_RX_CQE_PROFILE is ETHTOOL_A_PROFILE_IRQ_MODERATION.
> > So declare a policy for IRQ_MODERATION which has one entry -> nested
> > profile policy?
>
> Still
On Mon, 22 Apr 2024 17:00:25 +0800 Heng Qi wrote:
> 在 2024/4/19 上午8:48, Jakub Kicinski 写道:
> > On Wed, 17 Apr 2024 23:55:44 +0800 Heng Qi wrote:
> >> $ ethtool -c ethx
> >> ...
> >> rx-eqe-profile:
> >> {.usec = 1, .pkts = 256, .comps = 0,},
On Wed, 17 Apr 2024 23:55:44 +0800 Heng Qi wrote:
> $ ethtool -c ethx
> ...
> rx-eqe-profile:
> {.usec = 1, .pkts = 256, .comps = 0,},
> {.usec = 8, .pkts = 256, .comps = 0,},
> {.usec = 64, .pkts = 256, .comps = 0,},
> {.usec = 128, .pkts = 256, .comps = 0,},
> {.usec = 256, .pkts = 2
On Fri, 22 Mar 2024 14:35:36 +0200 Jarkko Sakkinen wrote:
> +TCG PTP Specification defines two interface types: FIFO and CRB. The former
> is
Could be worth spelling out the PTP part here, I'm guessing
get_maintainer made you CC netdev because it thought it stands
for Precision Time Protocol. And
On Mon, 26 Feb 2024 12:58:43 -0700 Jonathan Corbet wrote:
> Jakub Kicinski writes:
> > On Mon, 26 Feb 2024 14:24:39 -0500 Konstantin Ryabitsev wrote:
> >> In general, my previous experience enabling libravatar on git.kernel.org
> >> has
> >> taught me that m
On Mon, 26 Feb 2024 14:24:39 -0500 Konstantin Ryabitsev wrote:
> In general, my previous experience enabling libravatar on git.kernel.org has
> taught me that many very vocal people *really* don't like to have any kind of
> statistics gathered about them. However, if it's just for docs.kernel.org,
aster than other subsystems. Or so I feel after
hearing people talk about review rates at LPC.
Clarify in the doc that if the discussion went idle for a week
on netdev, 95% of the time there's no point waiting longer.
Signed-off-by: Jakub Kicinski
---
v2:
- rephrase the first para
On Sat, 18 Nov 2023 20:09:43 +0100 Andrew Lunn wrote:
> > +On the other hand, due to the volume of development discussions on netdev
> > +are very unlikely to be reignited after a week of silence.
>
> My English parse falls over on 'are', and wants to backtrack and try
> alternatives.
>
> Maybe
aster than other subsystems. Or so I feel after
hearing people talk about review rates at LPC.
Clarify in the doc that if the discussion went idle for a week
on netdev, 95% of the time there's no point waiting longer.
Signed-off-by: Jakub Kicinski
---
CC: cor...@lwn.net
CC: workfl...@vger.kerne
On Thu, 16 Nov 2023 12:11:51 -0800 Kees Cook wrote:
> The netdev subsystem has had a subsystem process document for a while now.
I wasn't sure if it's technically a profile or not.
Let me widen the CC a bit and see if someone can tell us one way
or the other. Our process doc is not listed in
Doc
On Tue, 17 Oct 2023 17:22:02 -0700 Jakub Kicinski wrote:
> Hi Arnd, the WiFi changes are now in net, could you rebase & repost?
s/net/net-next/ to be more clear this time..
1 - 100 of 127 matches
Mail list logo
