On Mon, Jan 11, 2021 at 6:54 PM Li,Rongqing wrote:
>
>
>
> > -Original Message-
> > From: Alexander Duyck [mailto:alexander.du...@gmail.com]
> > Sent: Tuesday, January 12, 2021 4:54 AM
> > To: Li,Rongqing
> > Cc: Netdev ; intel-wired-lan
> >
On Mon, Jan 11, 2021 at 10:56 PM Leon Romanovsky wrote:
>
> On Mon, Jan 11, 2021 at 11:30:39AM -0800, Alexander Duyck wrote:
> > On Sun, Jan 10, 2021 at 7:10 AM Leon Romanovsky wrote:
> > >
> > > From: Leon Romanovsky
> > >
> > > Some SR-IOV
On Mon, Jan 11, 2021 at 10:39 PM Leon Romanovsky wrote:
>
> On Mon, Jan 11, 2021 at 11:30:33AM -0800, Alexander Duyck wrote:
> > On Sun, Jan 10, 2021 at 7:12 AM Leon Romanovsky wrote:
> > >
> > > From: Leon Romanovsky
> > >
> > > Extend PCI
On Mon, Jan 11, 2021 at 9:14 PM Xin Long wrote:
>
> On Tue, Jan 12, 2021 at 12:48 AM Alexander Duyck
> wrote:
> >
> > On Mon, Jan 11, 2021 at 5:22 AM Xin Long wrote:
> > >
> > > This patch is to let it always do CRC checksum in sctp_gso_segment()
> >
On 1/12/21 1:16 PM, Alexander Lobakin wrote:
Commit 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.") actually
not only added a support for fraglisted UDP GRO, but also tweaked
some logics the way that non-fraglisted UDP GRO started to work for
forwarding too.
Tests showed that currently forwar
On Tue, Jan 12, 2021 at 6:43 PM rohit maheshwari wrote:
>
>
> On 07/01/21 12:47 AM, Jakub Kicinski wrote:
> > On Wed, 6 Jan 2021 23:23:27 +0530 Rohit Maheshwari wrote:
> >> Mandating NETIF_F_HW_CSUM to enable TLS offload feature is wrong.
> >> And it broke tls offload feature for the drivers, whi
eused,
> which means that the skb data area is passed to the Rx HW ring!
>
> To work around this, the page count is stored prior calling
> xdp_do_redirect().
>
> Fixes: 9cbc948b5a20 ("igb: add XDP support")
> Signed-off-by: Li RongQing
Looks good.
Reviewed-by: Alexander Duyck
> @@ -515,6 +519,7 @@ struct sk_buff *__napi_alloc_skb(struct napi_struct
> *napi, unsigned int len,
> goto skb_success;
> }
>
> + nc = this_cpu_ptr(&napi_alloc_cache);
> len += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
> len = SKB
On Tue, Jan 12, 2021 at 10:09 PM Leon Romanovsky wrote:
>
> On Tue, Jan 12, 2021 at 01:59:51PM -0800, Alexander Duyck wrote:
> > On Mon, Jan 11, 2021 at 10:39 PM Leon Romanovsky wrote:
> > >
> > > On Mon, Jan 11, 2021 at 11:30:33AM -0800, Alexander Duyck wrote:
>
On Tue, Jan 12, 2021 at 10:19 PM Leon Romanovsky wrote:
>
> On Tue, Jan 12, 2021 at 01:34:50PM -0800, Alexander Duyck wrote:
> > On Mon, Jan 11, 2021 at 10:56 PM Leon Romanovsky wrote:
> > >
> > > On Mon, Jan 11, 2021 at 11:30:39AM -0800, Alexander Duyck wrote:
>
On Wed, Jan 13, 2021 at 1:46 AM Xin Long wrote:
>
> On Wed, Jan 13, 2021 at 10:11 AM Alexander Duyck
> wrote:
> >
> > On Mon, Jan 11, 2021 at 9:14 PM Xin Long wrote:
> > >
> > > On Tue, Jan 12, 2021 at 12:48 AM Alexander Duyck
> > > wrote:
>
On Wed, Jan 13, 2021 at 10:50 PM Leon Romanovsky wrote:
>
> On Wed, Jan 13, 2021 at 02:44:45PM -0800, Alexander Duyck wrote:
> > On Tue, Jan 12, 2021 at 10:19 PM Leon Romanovsky wrote:
> > >
> > > On Tue, Jan 12, 2021 at 01:34:50PM -0800, Alexander Duyck wrote:
>
On Wed, Jan 13, 2021 at 11:16 PM Leon Romanovsky wrote:
>
> On Wed, Jan 13, 2021 at 12:00:00PM -0800, Alexander Duyck wrote:
> > On Tue, Jan 12, 2021 at 10:09 PM Leon Romanovsky wrote:
> > >
> > > On Tue, Jan 12, 2021 at 01:59:51PM -0800, Alexander Duyck wrote:
>
On Thu, Jan 14, 2021 at 8:49 AM Jason Gunthorpe wrote:
>
> On Thu, Jan 14, 2021 at 08:40:14AM -0800, Alexander Duyck wrote:
>
> > Where I think you and I disagree is that I really think the MSI-X
> > table size should be fixed at one value for the life of the VF.
> > In
On Thu, Jan 14, 2021 at 10:29 AM Jason Gunthorpe wrote:
>
> On Thu, Jan 14, 2021 at 09:55:24AM -0800, Alexander Duyck wrote:
> > On Thu, Jan 14, 2021 at 8:49 AM Jason Gunthorpe wrote:
> > >
> > > On Thu, Jan 14, 2021 at 08:40:14AM -0800, Alexander Duyck wrote:
>
On Thu, Jan 14, 2021 at 12:08 PM Jason Gunthorpe wrote:
>
> On Thu, Jan 14, 2021 at 11:24:12AM -0800, Alexander Duyck wrote:
>
> > > As you say BAR and MSI vector table are not so different, it seems
> > > perfectly in line with current PCI sig thinking to allow res
On Thu, Jan 14, 2021 at 3:28 PM Alex Williamson
wrote:
>
> On Thu, 14 Jan 2021 13:43:57 -0800
> Alexander Duyck wrote:
>
> > On Thu, Jan 14, 2021 at 12:08 PM Jason Gunthorpe wrote:
> > >
> > > On Thu, Jan 14, 2021 at 11:24:12AM -0800, Alexander Duyck wrote
On Thu, Jan 14, 2021 at 4:33 PM Wei Wang wrote:
>
> This patch allows running each napi poll loop inside its own
> kernel thread.
> The threaded mode could be enabled through napi_set_threaded()
> api, and does not require a device up/down. The kthread gets
> created on demand when napi_set_thread
On Thu, Jan 14, 2021 at 4:34 PM Wei Wang wrote:
>
> This patch adds a new sysfs attribute to the network device class.
> Said attribute provides a per-device control to enable/disable the
> threaded mode for all the napi instances of the given network device.
>
> Co-developed-by: Paolo Abeni
> Si
On Thu, Jan 14, 2021 at 7:14 PM Alexander Duyck
wrote:
>
> On Thu, Jan 14, 2021 at 4:33 PM Wei Wang wrote:
> >
> > +void napi_enable(struct napi_struct *n)
> > +{
> > + BUG_ON(!test_bit(NAPI_STATE_SCHED, &n->state));
> > + smp
On Thu, Jan 14, 2021 at 9:39 PM rohit maheshwari wrote:
>
>
> On 13/01/21 10:37 PM, Tariq Toukan wrote:
> >
> >
> > On 1/13/2021 5:35 AM, Alexander Duyck wrote:
> >> On Tue, Jan 12, 2021 at 6:43 PM rohit maheshwari
> >> wrote:
> >>&g
On Fri, Jan 15, 2021 at 1:54 PM Wei Wang wrote:
>
> On Thu, Jan 14, 2021 at 7:34 PM Alexander Duyck
> wrote:
> >
> > On Thu, Jan 14, 2021 at 4:34 PM Wei Wang wrote:
> > >
> > > This patch adds a new sysfs attribute to the network device class.
> > &
ange to do "hsize <= 0" check instead of "!hsize", and also move
> "hsize < 0" into else block, to save some cycles, as Alex suggested.
>
> Signed-off-by: Xin Long
Looks good to me.
Reviewed-by: Alexander Duyck
> ---
> net/core/skbuff.c | 1
On Fri, Jan 15, 2021 at 7:53 AM Leon Romanovsky wrote:
>
> On Fri, Jan 15, 2021 at 10:06:19AM -0400, Jason Gunthorpe wrote:
> > On Thu, Jan 14, 2021 at 05:56:20PM -0800, Alexander Duyck wrote:
> >
> > > That said, it only works at the driver level. So if the firmwa
On Fri, Jan 15, 2021 at 4:44 PM Wei Wang wrote:
>
> On Fri, Jan 15, 2021 at 3:08 PM Alexander Duyck
> wrote:
> >
> > On Fri, Jan 15, 2021 at 1:54 PM Wei Wang wrote:
> > >
> > > On Thu, Jan 14, 2021 at 7:34 PM Alexander Duyck
> > > wrote:
> >
On Fri, Jan 15, 2021 at 6:06 AM Jason Gunthorpe wrote:
>
> On Thu, Jan 14, 2021 at 05:56:20PM -0800, Alexander Duyck wrote:
>
> > That said, it only works at the driver level. So if the firmware is
> > the one that is having to do this it also occured to me that if this
>
On Sat, Jan 16, 2021 at 12:20 AM Leon Romanovsky wrote:
>
> On Fri, Jan 15, 2021 at 05:48:59PM -0800, Alexander Duyck wrote:
> > On Fri, Jan 15, 2021 at 7:53 AM Leon Romanovsky wrote:
> > >
> > > On Fri, Jan 15, 2021 at 10:06:19AM -0400, Jason Gunthorpe wrote:
>
On Mon, Jan 18, 2021 at 5:28 AM Leon Romanovsky wrote:
>
> On Mon, Jan 18, 2021 at 09:20:08AM +0200, Leon Romanovsky wrote:
> > On Sun, Jan 17, 2021 at 07:16:30PM -0800, Alexander Duyck wrote:
> > > On Sat, Jan 16, 2021 at 12:20 AM Leon Romanovsky wrote:
> > > >
> -Original Message-
> From: Paolo Abeni
> Sent: Tuesday, January 19, 2021 4:31 AM
> To: netdev@vger.kernel.org
> Cc: David S . Miller ; Jakub Kicinski
> ; Alexander Duyck ; Xin Long
>
> Subject: [PATCH net-next] net: fix GSO for SG-enabled devices.
>
>
On Fri, Jan 15, 2021 at 8:34 PM Xin Long wrote:
>
> When enabling encap for a ipv6 socket without udp_encap_needed_key
> increased, UDP GRO won't work for v4 mapped v6 address packets as
> sk will be NULL in udp4_gro_receive().
>
> This patch is to enable it by increasing udp_encap_needed_key for
On Fri, Jan 15, 2021 at 8:35 PM Xin Long wrote:
>
> As udp_encap_enable() is already called in udp_tunnel_encap_enable()
> since the last patch, and we don't need it any more. So remove it by
> reverting commit 81f954a44567567c7d74a97b1db78fb43afc253d.
>
> v1->v2:
> - no change.
> v2->v3:
> - ad
es.
>
> Suggested-by: Alexander Duyck
> Signed-off-by: Xin Long
One minor nit. If you had to resubmit this I might move the ionic
driver code into a separate patch. However It can probably be accepted
as is.
Reviewed-by: Alexander Duyck
> ---
> drivers/net/ethernet/pensando/ionic/i
;
> So this patch also makes igb support SCTP CRC checksum offload
> for UDP and GRE encapped packets.
>
> Signed-off-by: Xin Long
Reviewed-by: Alexander Duyck
r.
>
> Signed-off-by: Xin Long
Reviewed-by: Alexander Duyck
r.
>
> Signed-off-by: Xin Long
Reviewed-by: Alexander Duyck
r.
>
> Signed-off-by: Xin Long
Reviewed-by: Alexander Duyck
r.
>
> Signed-off-by: Xin Long
Reviewed-by: Alexander Duyck
On Tue, Jan 19, 2021 at 7:35 PM Wei Wang wrote:
>
> This patch adds a new sysfs attribute to the network device class.
> Said attribute provides a per-device control to enable/disable the
> threaded mode for all the napi instances of the given network device.
> User sets it to 1 or 0 to enable or
On Wed, Jan 20, 2021 at 10:07 AM Wei Wang wrote:
>
> On Wed, Jan 20, 2021 at 8:13 AM Alexander Duyck
> wrote:
> >
> > On Tue, Jan 19, 2021 at 7:35 PM Wei Wang wrote:
> > >
> > > This patch adds a new sysfs attribute to the network device class.
> > &
On Thu, Jan 21, 2021 at 12:46 AM Xin Long wrote:
>
> This patch is to extend csum_type field to 2 bits, and introduce
> CSUM_T_IP_GENERIC csum type, and add the support for this in
> skb_csum_hwoffload_help(), just like CSUM_T_SCTP_CRC.
>
> Note here it moves dst_pending_confirm field below ndisc_
On Thu, Jan 21, 2021 at 7:18 PM Xin Long wrote:
>
> On Fri, Jan 22, 2021 at 2:13 AM Alexander Duyck
> wrote:
> >
> > On Thu, Jan 21, 2021 at 12:46 AM Xin Long wrote:
> > >
> > > This patch is to extend csum_type field to 2 bits, and introduce
> &g
should probably
be pushed for any of the other Intel drivers that follow a similar
model as I suspect they were exhibit the same symptom with "ethtool
-t" triggering a NULL pointer dereference.
Reviewed-by: Alexander Duyck
> ---
> v2:
> * fix commit log
> ---
> drivers/
On Wed, Dec 9, 2020 at 6:44 AM Hans de Goede wrote:
>
> Hi,
>
> On 12/8/20 5:14 PM, Alexander Duyck wrote:
> > On Tue, Dec 8, 2020 at 1:30 AM Hans de Goede wrote:
> >>
> >> Hi,
> >>
> >> On 12/8/20 6:08 AM, Neftin, Sasha wrote:
> >>&
On Thu, Dec 10, 2020 at 9:05 AM Maciej Fijalkowski
wrote:
>
> On Thu, Dec 10, 2020 at 05:32:41PM +0100, Lorenzo Bianconi wrote:
> > > On Thu, Dec 10, 2020 at 04:50:42PM +0100, Lorenzo Bianconi wrote:
> > > > Introduce xdp_init_buff utility routine to initialize xdp_buff data
> > > > structure. Rel
From: Alexander Duyck
In the case of a fastopen SYN there are cases where it may trigger either a
ICMP_TOOBIG message in the case of IPv6 or a fragmentation request in the
case of IPv4. This results in the socket stalling for a second or more as
it does not respond to the message by
On Thu, Dec 10, 2020 at 10:24 PM Eric Dumazet wrote:
>
> On Fri, Dec 11, 2020 at 2:55 AM Alexander Duyck
> wrote:
> >
> > From: Alexander Duyck
> >
> > In the case of a fastopen SYN there are cases where it may trigger either a
> > ICMP_TOOBIG message
On Fri, Dec 11, 2020 at 8:22 AM Eric Dumazet wrote:
>
> On Fri, Dec 11, 2020 at 5:03 PM Alexander Duyck
> wrote:
>
> > That's fine. I can target this for net-next. I had just selected net
> > since I had considered it a fix, but I suppose it could be considered
&g
On Fri, Dec 11, 2020 at 11:18 AM Eric Dumazet wrote:
>
> On Fri, Dec 11, 2020 at 6:15 PM Alexander Duyck
> wrote:
> >
> > On Fri, Dec 11, 2020 at 8:22 AM Eric Dumazet wrote:
> > >
> > > On Fri, Dec 11, 2020 at 5:03 PM Alexander Duyck
> > > wro
From: Alexander Duyck
There are cases where a fastopen SYN may trigger either a ICMP_TOOBIG
message in the case of IPv6 or a fragmentation request in the case of
IPv4. This results in the socket stalling for a second or more as it does
not respond to the message by retransmitting the SYN frame
On Sat, Dec 12, 2020 at 10:34 AM Yuchung Cheng wrote:
>
> On Fri, Dec 11, 2020 at 5:28 PM Alexander Duyck
> wrote:
> >
> > From: Alexander Duyck
> >
> > There are cases where a fastopen SYN may trigger either a ICMP_TOOBIG
> > message in the case of IPv6
On Sat, Dec 12, 2020 at 11:07 AM Yuchung Cheng wrote:
>
> On Sat, Dec 12, 2020 at 11:01 AM Alexander Duyck
> wrote:
> >
> > On Sat, Dec 12, 2020 at 10:34 AM Yuchung Cheng wrote:
> > >
> > > On Fri, Dec 11, 2020 at 5:28 PM Alexander Duyck
> > &g
From: Alexander Duyck
There are cases where a fastopen SYN may trigger either a ICMP_TOOBIG
message in the case of IPv6 or a fragmentation request in the case of
IPv4. This results in the socket stalling for a second or more as it does
not respond to the message by retransmitting the SYN frame
From: Alexander Duyck
There are cases where a fastopen SYN may trigger either a ICMP_TOOBIG
message in the case of IPv6 or a fragmentation request in the case of
IPv4. This results in the socket stalling for a second or more as it does
not respond to the message by retransmitting the SYN frame
htool.c | 40 ++
> drivers/net/ethernet/intel/e1000e/ich8lan.c | 4 +-
> drivers/net/ethernet/intel/e1000e/netdev.c | 59 -
> 4 files changed, 53 insertions(+), 51 deletions(-)
>
The changes look good to me.
Reviewed-by: Alexander Duyck
On Mon, Dec 14, 2020 at 1:49 PM Saeed Mahameed wrote:
>
> From: Parav Pandit
>
> MLX5_GENERAL_OBJECT_TYPES types bitfield is 64-bit field.
>
> Defining an enum for such bit fields on 32-bit platform results in below
> warning.
>
> ./include/vdso/bits.h:7:26: warning: left shift count >= width of
On Mon, Dec 14, 2020 at 1:49 PM Saeed Mahameed wrote:
>
> Hi Dave, Jakub, Jason,
>
> This series form Parav was the theme of this mlx5 release cycle,
> we've been waiting anxiously for the auxbus infrastructure to make it into
> the kernel, and now as the auxbus is in and all the stars are aligned
On Mon, Dec 14, 2020 at 6:44 PM David Ahern wrote:
>
> On 12/14/20 6:53 PM, Alexander Duyck wrote:
> >> example subfunction usage sequence:
> >> ---
> >> Change device to switchdev mode:
> >> $ devlink dev eswitch set pci/0
On Mon, Dec 14, 2020 at 9:48 PM Parav Pandit wrote:
>
>
> > From: Alexander Duyck
> > Sent: Tuesday, December 15, 2020 7:24 AM
> >
> > On Mon, Dec 14, 2020 at 1:49 PM Saeed Mahameed
> > wrote:
> > >
> > > Hi Dave, Jakub, Jason,
> > &g
On Mon, Dec 14, 2020 at 10:15 PM Saeed Mahameed wrote:
>
> On Mon, 2020-12-14 at 17:53 -0800, Alexander Duyck wrote:
> > On Mon, Dec 14, 2020 at 1:49 PM Saeed Mahameed
> > wrote:
> > > Hi Dave, Jakub, Jason,
> > >
> > > This series form Parav was the
On Tue, Dec 15, 2020 at 12:35 PM Saeed Mahameed wrote:
>
> On Tue, 2020-12-15 at 11:12 -0800, Alexander Duyck wrote:
> > On Mon, Dec 14, 2020 at 10:15 PM Saeed Mahameed
> > wrote:
> > > On Mon, 2020-12-14 at 17:53 -0800, Alexander Duyck wrote:
> > > >
On Tue, Dec 15, 2020 at 4:20 PM Jason Gunthorpe wrote:
>
> On Tue, Dec 15, 2020 at 01:41:04PM -0800, Alexander Duyck wrote:
>
> > > not just devlink and switchdev, auxbus was also introduced to
> > > standardize some of the interfaces.
> >
> > The auxbus is
On Tue, Dec 15, 2020 at 5:13 PM Edwin Peer wrote:
>
> On Tue, Dec 15, 2020 at 10:49 AM Alexander Duyck
> wrote:
>
> > It isn't "SR-IOV done right" it seems more like "VMDq done better".
>
> I don't think I agree with that assertion. The fa
On Tue, Dec 15, 2020 at 7:04 PM Jason Gunthorpe wrote:
>
> On Tue, Dec 15, 2020 at 06:19:18PM -0800, Alexander Duyck wrote:
>
> > > > I would really like to see is a solid standardization of what this is.
> > > > Otherwise the comparison is going to be made. Es
On Wed, Dec 16, 2020 at 5:33 AM Jason Gunthorpe wrote:
>
> On Tue, Dec 15, 2020 at 08:13:21PM -0800, Alexander Duyck wrote:
>
> > > > Ugh, don't get me started on switchdev. The biggest issue as I see it
> > > > with switchev is that you have to have a tru
On Wed, Dec 16, 2020 at 9:51 AM Jason Gunthorpe wrote:
>
> On Wed, Dec 16, 2020 at 08:31:44AM -0800, Alexander Duyck wrote:
>
> > You say this will scale better but I am not even sure about that. The
> > fact is SR-IOV could scale to 256 VFs, but for networking I kind of
>
On Wed, Dec 16, 2020 at 12:35 PM Jason Gunthorpe wrote:
>
> On Wed, Dec 16, 2020 at 11:27:32AM -0800, Alexander Duyck wrote:
>
> > That has been the case for a long time. However it had been my
> > experience that SR-IOV never scaled well to meet those needs and so it
> &g
On Wed, Dec 16, 2020 at 4:38 PM Jason Gunthorpe wrote:
>
> On Wed, Dec 16, 2020 at 02:53:07PM -0800, Alexander Duyck wrote:
>
> > It isn't about the association, it is about who is handling the
> > traffic. Going back to the macvlan model what we did is we had a group
On Thu, Dec 17, 2020 at 11:40 AM Jason Gunthorpe wrote:
>
> On Thu, Dec 17, 2020 at 10:48:48AM -0800, Alexander Duyck wrote:
>
> > Just to clarify I am not with Intel, nor do I plan to work on any
> > Intel drivers related to this.
>
> Sure
>
> > I disagree
On Thu, Dec 17, 2020 at 5:30 PM David Ahern wrote:
>
> On 12/16/20 3:53 PM, Alexander Duyck wrote:
> > The problem in my case was based on a past experience where east-west
> > traffic became a problem and it was easily shown that bypassing the
> > NIC for traffic was sign
On Thu, Dec 17, 2020 at 7:55 PM David Ahern wrote:
>
> On 12/17/20 8:11 PM, Alexander Duyck wrote:
> > On Thu, Dec 17, 2020 at 5:30 PM David Ahern wrote:
> >>
> >> On 12/16/20 3:53 PM, Alexander Duyck wrote:
> >>> The problem in my case was
On Thu, Dec 17, 2020 at 9:20 PM Parav Pandit wrote:
>
>
> > From: Alexander Duyck
> > Sent: Friday, December 18, 2020 8:41 AM
> >
> > On Thu, Dec 17, 2020 at 5:30 PM David Ahern wrote:
> > >
> > > On 12/16/20 3:53 PM, Alexander Duyck wrote
On Fri, Dec 18, 2020 at 10:01 AM Parav Pandit wrote:
>
>
> > From: Alexander Duyck
> > Sent: Friday, December 18, 2020 9:31 PM
> >
> > On Thu, Dec 17, 2020 at 9:20 PM Parav Pandit wrote:
> > >
> > >
> > > > From: Alex
On Fri, Dec 18, 2020 at 12:18 PM Jason Gunthorpe wrote:
>
> On Fri, Dec 18, 2020 at 11:22:12AM -0800, Alexander Duyck wrote:
>
> > Also as far as the patch count complaints I have seen in a few threads
> > I would be fine with splitting things up so that the devlink and au
On Fri, Dec 18, 2020 at 4:30 PM Jakub Kicinski wrote:
>
> On Thu, 17 Dec 2020 17:25:18 +0100 Antoine Tenart wrote:
> > Callers to netif_set_xps_queue should take the rtnl lock. Failing to do
> > so can lead to race conditions between netdev_set_num_tc and
> > netif_set_xps_queue, triggering variou
On Mon, Dec 21, 2020 at 11:36 AM Antoine Tenart wrote:
>
> Accesses to dev->xps_cpus_map (when using dev->num_tc) should be
> protected by the xps_map mutex, to avoid possible race conditions when
> dev->num_tc is updated while the map is accessed. This patch moves the
> logic accessing dev->xps_c
On Mon, Dec 21, 2020 at 11:36 AM Antoine Tenart wrote:
>
> Two race conditions can be triggered in xps, resulting in various oops
> and invalid memory accesses:
>
> 1. Calling netdev_set_num_tc while netif_set_xps_queue:
>
>- netdev_set_num_tc sets dev->tc_num.
>
>- netif_set_xps_queue use
On Tue, Dec 22, 2020 at 1:21 AM Antoine Tenart wrote:
>
> Hello Alexander, Jakub,
>
> Quoting Alexander Duyck (2020-12-22 00:21:57)
> >
> > Looking over this patch it seems kind of obvious that extending the
> > xps_map_mutex is making things far mor
elia Groza
The changes to the Intel drivers look fine to me, although it might be
nice to have someone from Intel provide a review/ack. I've added
intel-wired-lan to the thread so that someone from Intel can hopefully
review and also ack this.
Reviewed-by: Alexander Duyck
On Mon, Nov 30, 2020 at 1:32 PM Tony Nguyen wrote:
>
> From: Mario Limonciello
>
> S0ix for GBE flows are needed for allowing the system to get into deepest
> power state, but these require coordination of components outside of
> control of Linux kernel. For systems that have confirmed to coordi
On Mon, Nov 30, 2020 at 2:16 PM Limonciello, Mario
wrote:
>
> >
> > Generally the use of module parameters and sysfs usage are frowned
> > upon.
>
> I was trying to build on the existing module parameters that existed
> already for e1000e. So I guess I would ask, why are those not done in
> ethto
On Mon, Nov 30, 2020 at 1:32 PM Tony Nguyen wrote:
>
> From: Mario Limonciello
>
> Dell's Comet Lake Latitude and Precision systems containing i219LM are
> properly configured and should use the s0ix flows.
>
> Signed-off-by: Mario Limonciello
> Tested-by: Yijun Shen
> Signed-off-by: Tony Nguye
On Wed, Dec 2, 2020 at 10:24 AM David Awogbemila wrote:
>
> From: Catherine Sullivan
>
> During TX, skbs' data addresses are dma_map'ed and passed to the NIC.
> This means that the device can perform DMA directly from these addresses
> and the driver does not have to copy the buffer content into
gt; drivers/net/ethernet/google/gve/gve_tx.c | 202 --
> 8 files changed, 577 insertions(+), 164 deletions(-)
>
> --
> 2.29.2.576.ga3fc446d84-goog
>
Other than the few nits with counters being u32 values I didn't really
see much else.
Reviewed-by: Alexander Duyck
On Fri, Dec 4, 2020 at 12:09 PM Mario Limonciello
wrote:
>
> Introduce a flag to indicate the device should be using the S0ix
> flows and use this flag to run those functions.
>
> Splitting the code to it's own file will make future heuristics
> more self contained.
>
> Tested-by: Yijun Shen
> Si
ook good to me. Just need to address the minor issue that
seems to have been present prior to the introduction of this patch
set.
Reviewed-by: Alexander Duyck
On Fri, Dec 4, 2020 at 2:28 PM Limonciello, Mario
wrote:
>
> > -Original Message-
> > From: Alexander Duyck
> > Sent: Friday, December 4, 2020 15:27
> > To: Limonciello, Mario
> > Cc: Jeff Kirsher; Tony Nguyen; intel-wired-lan; LKML; Linux PM; Netde
On Sat, Dec 5, 2020 at 3:49 PM Jakub Kicinski wrote:
>
> On Fri, 4 Dec 2020 14:38:03 -0800 Alexander Duyck wrote:
> > > > The patches look good to me. Just need to address the minor issue that
> > > > seems to have been present prior to the introduc
On Fri, Dec 4, 2020 at 4:15 AM wrote:
>
> From: Arthur Kiyanovski
>
> This patch adds explicit casting to some implicit conversions in the ena
> driver. The implicit conversions fail some of our static checkers that
> search for accidental conversions in our driver.
> Adding this cast won't affec
On Mon, Dec 7, 2020 at 8:36 AM Lorenzo Bianconi wrote:
>
> Initialize multi-buffer bit (mb) to 0 in all XDP-capable drivers.
> This is a preliminary patch to enable xdp multi-buffer support.
>
> Signed-off-by: Lorenzo Bianconi
I'm really not a fan of this design. Having to update every driver in
On Mon, Dec 7, 2020 at 8:36 AM Lorenzo Bianconi wrote:
>
> Introduce multi-buffer bit (mb) in xdp_frame/xdp_buffer data structure
> in order to specify if this is a linear buffer (mb = 0) or a multi-buffer
> frame (mb = 1). In the latter case the shared_info area at the end of the
> first buffer i
On Mon, Dec 7, 2020 at 3:03 PM Saeed Mahameed wrote:
>
> On Mon, 2020-12-07 at 13:16 -0800, Alexander Duyck wrote:
> > On Mon, Dec 7, 2020 at 8:36 AM Lorenzo Bianconi
> > wrote:
> > > Introduce multi-buffer bit (mb) in xdp_frame/xdp_buffer data
> > > structu
+++-----
> drivers/net/ethernet/google/gve/gve_tx.c | 197 --
> 8 files changed, 574 insertions(+), 162 deletions(-)
>
> Reviewed-by: Alexander Duyck
Normally the reviewed-by should be included on the individual patches
instead of here. It can be moved if you end up needing to resubmit.
On Tue, Dec 8, 2020 at 1:30 AM Hans de Goede wrote:
>
> Hi,
>
> On 12/8/20 6:08 AM, Neftin, Sasha wrote:
> > On 12/7/2020 17:41, Limonciello, Mario wrote:
> >>> First of all thank you for working on this.
> >>>
> >>> I must say though that I don't like the approach taken here very
> >>> much.
> >>
On Tue, Dec 8, 2020 at 8:58 AM Nguyen, Anthony L
wrote:
>
> On Mon, 2020-11-23 at 17:11 -0800, Alexander Duyck wrote:
> > On Mon, Nov 23, 2020 at 3:21 PM Jesse Brandeburg
> > wrote:
> > >
> > > Alexander Duyck wrote:
> > >
> > > > >
On Tue, Dec 8, 2020 at 2:01 PM Nguyen, Anthony L
wrote:
>
> On Tue, 2020-12-08 at 11:00 -0800, Alexander Duyck wrote:
> > On Tue, Dec 8, 2020 at 8:58 AM Nguyen, Anthony L
> > wrote:
> > >
> > > On Mon, 2020-11-23 at 17:11 -0800, Alexander Duyck wrote:
>
On Mon, Nov 16, 2020 at 1:17 AM Xin Long wrote:
>
> This patch is to let it always do CRC checksum in sctp_gso_segment()
> by removing CRC flag from the dev features in gre_gso_segment() for
> SCTP over GRE, just as it does in Commit 527beb8ef9c0 ("udp: support
> sctp over udp in skb_udp_tunnel_se
On Wed, Nov 18, 2020 at 3:15 PM David Awogbemila wrote:
>
> On Wed, Nov 11, 2020 at 9:20 AM Alexander Duyck
> wrote:
> >
> > On Mon, Nov 9, 2020 at 3:39 PM David Awogbemila
> > wrote:
> > >
> > > From: Catherine Sullivan
> > >
> > &
On Wed, Nov 18, 2020 at 3:16 PM David Awogbemila wrote:
>
> On Wed, Nov 11, 2020 at 9:29 AM Alexander Duyck
> wrote:
> >
> > On Mon, Nov 9, 2020 at 3:39 PM David Awogbemila
> > wrote:
> > >
> > > From: Catherine Sullivan
> > >
> > &g
On Wed, Nov 18, 2020 at 2:50 PM David Awogbemila wrote:
>
> On Wed, Nov 11, 2020 at 9:20 AM Alexander Duyck
> wrote:
> >
> > On Mon, Nov 9, 2020 at 3:39 PM David Awogbemila
> > wrote:
> > >
> > > This patch lets the driver reuse buffers that
Where is the description of what this patch set is meant to do? I
don't recall if I reviewed that in the last patch set but usually the
cover page should tell us something about the patch set and not just
be a list of changes which I assume are diffs from v3?
On Wed, Nov 18, 2020 at 3:22 PM David
1 - 100 of 1940 matches
Mail list logo
