* Re: [PATCH 1/4] lan78xx: Read MAC address from DT if present
From: Phil Elwell @ 2018-04-12 14:18 UTC (permalink / raw)
To: Andrew Lunn
Cc: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, David S. Miller, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Linus Walleij, Andrew Morton, Randy Dunlap,
netdev, devicetree, linux-kernel, linux-usb
In-Reply-To: <20180412140640.GL28963@lunn.ch>
Hi Andrew,
On 12/04/2018 15:06, Andrew Lunn wrote:
> Hi Phil
>
>> - ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
>> - ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
>> + mac_addr = of_get_mac_address(dev->udev->dev.of_node);
>
> It might be better to use the higher level eth_platform_get_mac_address().
OK - I'll take your word for it.
Phil
^ permalink raw reply
* Re: [PATCH 4/4] dt-bindings: Document the DT bindings for lan78xx
From: Andrew Lunn @ 2018-04-12 14:17 UTC (permalink / raw)
To: Phil Elwell
Cc: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, David S. Miller, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Linus Walleij, Andrew Morton, Randy Dunlap,
netdev, devicetree, linux-kernel, linux-usb
In-Reply-To: <0bcc10cd-2a25-311f-d006-ddefe47567dc@raspberrypi.org>
On Thu, Apr 12, 2018 at 03:10:57PM +0100, Phil Elwell wrote:
> Hi Andrew,
>
> On 12/04/2018 15:04, Andrew Lunn wrote:
> > On Thu, Apr 12, 2018 at 02:55:36PM +0100, Phil Elwell wrote:
> >> The Microchip LAN78XX family of devices are Ethernet controllers with
> >> a USB interface. Despite being discoverable devices it can be useful to
> >> be able to configure them from Device Tree, particularly in low-cost
> >> applications without an EEPROM or programmed OTP.
> >>
> >> Document the supported properties in a bindings file, adding it to
> >> MAINTAINERS at the same time.
> >
> > Hi Phil
> >
> > How you link an OF node to a USB device is not obvious. Could you
> > please include either a pointer to some binding documentation, or make
> > your example show it.
>
> Thanks for the feedback. Would you consider this (lifted from the Pi 3B+ Device Tree)
> a sufficient example?
Yes, this is good.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH 2/4] lan78xx: Read initial EEE setting from Device Tree
From: Andrew Lunn @ 2018-04-12 14:16 UTC (permalink / raw)
To: Phil Elwell
Cc: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, David S. Miller, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Linus Walleij, Andrew Morton, Randy Dunlap,
netdev, devicetree, linux-kernel, linux-usb
In-Reply-To: <1523541336-145953-3-git-send-email-phil@raspberrypi.org>
On Thu, Apr 12, 2018 at 02:55:34PM +0100, Phil Elwell wrote:
> Add two new Device Tree properties:
> * microchip,eee-enabled - a boolean to enable EEE
> * microchip,tx-lpi-timer - time in microseconds to wait after TX goes
> idle before entering the low power state
> (default 600)
Hi Phil
This looks wrong.
What should happen is that the MAC driver calls phy_init_eee() to find
out if the PHY supports EEE. There should be no need to look in device
tree.
Andrew
^ permalink raw reply
* Re: [RFC PATCH v2 00/14] Introducing AF_XDP support
From: Björn Töpel @ 2018-04-12 14:14 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: William Tu, Karlsson, Magnus, Alexander Duyck, Alexander Duyck,
John Fastabend, Jesper Dangaard Brouer, Willem de Bruijn,
Daniel Borkmann, Linux Kernel Network Developers,
Björn Töpel, michael.lundkvist, Brandeburg, Jesse,
Anjali Singhai Jain, Zhang, Qi Z, ravineet.singh
In-Reply-To: <bcfd90dd-4977-4f97-daec-c7128bcdb67e@fb.com>
2018-04-11 20:43 GMT+02:00 Alexei Starovoitov <ast@fb.com>:
> On 4/11/18 5:17 AM, Björn Töpel wrote:
>>
>>
>> In the current RFC you are required to create both an Rx and Tx
>> queue to bind the socket, which is just weird for your "Rx on one
>> device, Tx to another" scenario. I'll fix that in the next RFC.
>
> I would defer on adding new features until the key functionality
> lands. imo it's in good shape and I would submit it without RFC tag
> as soon as net-next reopens.
Yes, makes sense. We're doing some ptr_ring-like vs head/tail
measurements, and depending on the result we'll send out a proper
patch when net-next is open again.
What tree should we target -- bpf-next or net-next?
Thanks!
Björn
^ permalink raw reply
* Re: [PATCH 4/4] dt-bindings: Document the DT bindings for lan78xx
From: Phil Elwell @ 2018-04-12 14:10 UTC (permalink / raw)
To: Andrew Lunn
Cc: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, David S. Miller, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Linus Walleij, Andrew Morton, Randy Dunlap,
netdev, devicetree, linux-kernel, linux-usb
In-Reply-To: <20180412140409.GK28963@lunn.ch>
Hi Andrew,
On 12/04/2018 15:04, Andrew Lunn wrote:
> On Thu, Apr 12, 2018 at 02:55:36PM +0100, Phil Elwell wrote:
>> The Microchip LAN78XX family of devices are Ethernet controllers with
>> a USB interface. Despite being discoverable devices it can be useful to
>> be able to configure them from Device Tree, particularly in low-cost
>> applications without an EEPROM or programmed OTP.
>>
>> Document the supported properties in a bindings file, adding it to
>> MAINTAINERS at the same time.
>
> Hi Phil
>
> How you link an OF node to a USB device is not obvious. Could you
> please include either a pointer to some binding documentation, or make
> your example show it.
Thanks for the feedback. Would you consider this (lifted from the Pi 3B+ Device Tree)
a sufficient example?
&usb {
usb1@1 {
compatible = "usb424,2514";
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
usb1_1@1 {
compatible = "usb424,2514";
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
ethernet: usbether@1 {
compatible = "usb424,7800";
reg = <1>;
microchip,eee-enabled;
microchip,tx-lpi-timer = <600>; /* non-aggressive*/
/*
* led0 = 1:link1000/activity
* led1 = 6:link10/100/activity
*/
microchip,led-modes = <1 6>;
};
};
};
};
Phil
^ permalink raw reply
* Re: [PATCH net-next] Per interface IPv4 stats (CONFIG_IP_IFSTATS_TABLE)
From: kbuild test robot @ 2018-04-12 14:09 UTC (permalink / raw)
To: Stephen Suryaputra; +Cc: kbuild-all, netdev, Stephen Suryaputra
In-Reply-To: <1523415335-17154-1-git-send-email-ssuryaextr@gmail.com>
Hi Stephen,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Stephen-Suryaputra/Per-interface-IPv4-stats-CONFIG_IP_IFSTATS_TABLE/20180412-181719
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
net/ipv4/proc.c:414:28: sparse: Variable length array is used.
>> net/ipv4/proc.c:499:43: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:3>*mib @@ got vvoid [noderef] <asn:3>*mib @@
net/ipv4/proc.c:499:43: expected void [noderef] <asn:3>*mib
net/ipv4/proc.c:499:43: got void [noderef] <asn:3>**pcpumib
>> net/ipv4/proc.c:532:34: sparse: cast removes address space of expression
net/ipv4/proc.c:534:34: sparse: cast removes address space of expression
vim +499 net/ipv4/proc.c
411
412 static int snmp_seq_show_tcp_udp(struct seq_file *seq, void *v)
413 {
> 414 unsigned long buff[TCPUDP_MIB_MAX];
415 struct net *net = seq->private;
416 int i;
417
418 memset(buff, 0, TCPUDP_MIB_MAX * sizeof(unsigned long));
419
420 seq_puts(seq, "\nTcp:");
421 for (i = 0; snmp4_tcp_list[i].name; i++)
422 seq_printf(seq, " %s", snmp4_tcp_list[i].name);
423
424 seq_puts(seq, "\nTcp:");
425 snmp_get_cpu_field_batch(buff, snmp4_tcp_list,
426 net->mib.tcp_statistics);
427 for (i = 0; snmp4_tcp_list[i].name; i++) {
428 /* MaxConn field is signed, RFC 2012 */
429 if (snmp4_tcp_list[i].entry == TCP_MIB_MAXCONN)
430 seq_printf(seq, " %ld", buff[i]);
431 else
432 seq_printf(seq, " %lu", buff[i]);
433 }
434
435 memset(buff, 0, TCPUDP_MIB_MAX * sizeof(unsigned long));
436
437 snmp_get_cpu_field_batch(buff, snmp4_udp_list,
438 net->mib.udp_statistics);
439 seq_puts(seq, "\nUdp:");
440 for (i = 0; snmp4_udp_list[i].name; i++)
441 seq_printf(seq, " %s", snmp4_udp_list[i].name);
442 seq_puts(seq, "\nUdp:");
443 for (i = 0; snmp4_udp_list[i].name; i++)
444 seq_printf(seq, " %lu", buff[i]);
445
446 memset(buff, 0, TCPUDP_MIB_MAX * sizeof(unsigned long));
447
448 /* the UDP and UDP-Lite MIBs are the same */
449 seq_puts(seq, "\nUdpLite:");
450 snmp_get_cpu_field_batch(buff, snmp4_udp_list,
451 net->mib.udplite_statistics);
452 for (i = 0; snmp4_udp_list[i].name; i++)
453 seq_printf(seq, " %s", snmp4_udp_list[i].name);
454 seq_puts(seq, "\nUdpLite:");
455 for (i = 0; snmp4_udp_list[i].name; i++)
456 seq_printf(seq, " %lu", buff[i]);
457
458 seq_putc(seq, '\n');
459 return 0;
460 }
461
462 static int snmp_seq_show(struct seq_file *seq, void *v)
463 {
464 snmp_seq_show_ipstats(seq, v);
465
466 icmp_put(seq); /* RFC 2011 compatibility */
467 icmpmsg_put(seq);
468
469 snmp_seq_show_tcp_udp(seq, v);
470
471 return 0;
472 }
473
474 static int snmp_seq_open(struct inode *inode, struct file *file)
475 {
476 return single_open_net(inode, file, snmp_seq_show);
477 }
478
479 static const struct file_operations snmp_seq_fops = {
480 .open = snmp_seq_open,
481 .read = seq_read,
482 .llseek = seq_lseek,
483 .release = single_release_net,
484 };
485
486
487 #ifdef CONFIG_IP_IFSTATS_TABLE
488 static void snmp_seq_show_item(struct seq_file *seq, void __percpu **pcpumib,
489 atomic_long_t *smib,
490 const struct snmp_mib *itemlist,
491 char *prefix)
492 {
493 char name[32];
494 int i;
495 unsigned long val;
496
497 for (i = 0; itemlist[i].name; i++) {
498 val = pcpumib ?
> 499 snmp_fold_field64(pcpumib, itemlist[i].entry,
500 offsetof(struct ipstats_mib, syncp)) :
501 atomic_long_read(smib + itemlist[i].entry);
502 snprintf(name, sizeof(name), "%s%s",
503 prefix, itemlist[i].name);
504 seq_printf(seq, "%-32s\t%lu\n", name, val);
505 }
506 }
507
508 static void snmp_seq_show_icmpmsg(struct seq_file *seq, atomic_long_t *smib)
509 {
510 char name[32];
511 int i;
512 unsigned long val;
513
514 for (i = 0; i < ICMPMSG_MIB_MAX; i++) {
515 val = atomic_long_read(smib + i);
516 if (val) {
517 snprintf(name, sizeof(name), "Icmp%sType%u",
518 i & 0x100 ? "Out" : "In", i & 0xff);
519 seq_printf(seq, "%-32s\t%lu\n", name, val);
520 }
521 }
522 }
523
524 static int snmp_dev_seq_show(struct seq_file *seq, void *v)
525 {
526 struct in_device *idev = (struct in_device *)seq->private;
527
528 seq_printf(seq, "%-32s\t%u\n", "ifIndex", idev->dev->ifindex);
529
530 BUILD_BUG_ON(offsetof(struct ipstats_mib, mibs) != 0);
531
> 532 snmp_seq_show_item(seq, (void __percpu **)idev->stats.ip, NULL,
533 snmp4_ipstats_list, "Ip");
534 snmp_seq_show_item(seq, (void __percpu **)idev->stats.ip, NULL,
535 snmp4_ipextstats_list, "Ip");
536 snmp_seq_show_item(seq, NULL, idev->stats.icmpdev->mibs,
537 snmp4_icmp_list, "Icmp");
538 snmp_seq_show_icmpmsg(seq, idev->stats.icmpmsgdev->mibs);
539 return 0;
540 }
541
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH 1/4] lan78xx: Read MAC address from DT if present
From: Andrew Lunn @ 2018-04-12 14:06 UTC (permalink / raw)
To: Phil Elwell
Cc: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, David S. Miller, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Linus Walleij, Andrew Morton, Randy Dunlap,
netdev, devicetree, linux-kernel, linux-usb
In-Reply-To: <1523541336-145953-2-git-send-email-phil@raspberrypi.org>
Hi Phil
> - ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
> - ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
> + mac_addr = of_get_mac_address(dev->udev->dev.of_node);
It might be better to use the higher level eth_platform_get_mac_address().
Andrew
^ permalink raw reply
* Re: [RFC PATCH v2 03/14] xsk: add umem fill queue support and mmap
From: Michael S. Tsirkin @ 2018-04-12 14:04 UTC (permalink / raw)
To: Karlsson, Magnus
Cc: Björn Töpel, Duyck, Alexander H,
alexander.duyck@gmail.com, john.fastabend@gmail.com, ast@fb.com,
brouer@redhat.com, willemdebruijn.kernel@gmail.com,
daniel@iogearbox.net, netdev@vger.kernel.org,
michael.lundkvist@ericsson.com, Brandeburg, Jesse,
Singhai, Anjali, Zhang, Qi Z, ravineet.singh@ericsson.com
In-Reply-To: <AFED4FBCE79F3548A8F74434195ACE39588D1AA4@IRSMSX107.ger.corp.intel.com>
On Thu, Apr 12, 2018 at 07:38:25AM +0000, Karlsson, Magnus wrote:
> I think you are definitely right in that there are ways in which
> we can improve performance here. That said, the current queue
> performs slightly better than the previous one we had that was
> more or less a copy of one of your first virtio 1.1 proposals
> from little over a year ago. It had bidirectional queues and a
> valid flag in the descriptor itself. The reason we abandoned this
> was not poor performance (it was good), but a need to go to
> unidirectional queues. Maybe I should have only changed that
> aspect and kept the valid flag.
Is there a summary about unidirectional queues anywhere? I'm curious to
know whether there are any lessons here to be learned for virtio
or ptr_ring.
--
MST
^ permalink raw reply
* Re: [PATCH 4/4] dt-bindings: Document the DT bindings for lan78xx
From: Andrew Lunn @ 2018-04-12 14:04 UTC (permalink / raw)
To: Phil Elwell
Cc: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, David S. Miller, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Linus Walleij, Andrew Morton, Randy Dunlap,
netdev, devicetree, linux-kernel, linux-usb
In-Reply-To: <1523541336-145953-5-git-send-email-phil@raspberrypi.org>
On Thu, Apr 12, 2018 at 02:55:36PM +0100, Phil Elwell wrote:
> The Microchip LAN78XX family of devices are Ethernet controllers with
> a USB interface. Despite being discoverable devices it can be useful to
> be able to configure them from Device Tree, particularly in low-cost
> applications without an EEPROM or programmed OTP.
>
> Document the supported properties in a bindings file, adding it to
> MAINTAINERS at the same time.
Hi Phil
How you link an OF node to a USB device is not obvious. Could you
please include either a pointer to some binding documentation, or make
your example show it.
Thanks
Andrew
^ permalink raw reply
* [PATCH net 2/2] sfc: limit ARFS workitems in flight per channel
From: Edward Cree @ 2018-04-12 14:02 UTC (permalink / raw)
To: linux-net-drivers, David Miller; +Cc: netdev
In-Reply-To: <1713aaa9-2803-0d3b-127a-5240876da7b1@solarflare.com>
A misconfigured system (e.g. with all interrupts affinitised to all CPUs)
may produce a storm of ARFS steering events. With the existing sfc ARFS
implementation, that could create a backlog of workitems that grinds the
system to a halt. To prevent this, limit the number of workitems that
may be in flight for a given SFC device to 8 (EFX_RPS_MAX_IN_FLIGHT), and
return EBUSY from our ndo_rx_flow_steer method if the limit is reached.
Given this limit, also store the workitems in an array of slots within the
struct efx_nic, rather than dynamically allocating for each request.
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
drivers/net/ethernet/sfc/net_driver.h | 25 +++++++++++++++
drivers/net/ethernet/sfc/rx.c | 58 ++++++++++++++++++-----------------
2 files changed, 55 insertions(+), 28 deletions(-)
diff --git a/drivers/net/ethernet/sfc/net_driver.h b/drivers/net/ethernet/sfc/net_driver.h
index 5e379a83c729..eea3808b3f25 100644
--- a/drivers/net/ethernet/sfc/net_driver.h
+++ b/drivers/net/ethernet/sfc/net_driver.h
@@ -733,6 +733,27 @@ struct efx_rss_context {
u32 rx_indir_table[128];
};
+#ifdef CONFIG_RFS_ACCEL
+/**
+ * struct efx_async_filter_insertion - Request to asynchronously insert a filter
+ * @net_dev: Reference to the netdevice
+ * @spec: The filter to insert
+ * @work: Workitem for this request
+ * @rxq_index: Identifies the channel for which this request was made
+ * @flow_id: Identifies the kernel-side flow for which this request was made
+ */
+struct efx_async_filter_insertion {
+ struct net_device *net_dev;
+ struct efx_filter_spec spec;
+ struct work_struct work;
+ u16 rxq_index;
+ u32 flow_id;
+};
+
+/* Maximum number of ARFS workitems that may be in flight on an efx_nic */
+#define EFX_RPS_MAX_IN_FLIGHT 8
+#endif /* CONFIG_RFS_ACCEL */
+
/**
* struct efx_nic - an Efx NIC
* @name: Device name (net device name or bus id before net device registered)
@@ -850,6 +871,8 @@ struct efx_rss_context {
* @rps_expire_channel: Next channel to check for expiry
* @rps_expire_index: Next index to check for expiry in
* @rps_expire_channel's @rps_flow_id
+ * @rps_slot_map: bitmap of in-flight entries in @rps_slot
+ * @rps_slot: array of ARFS insertion requests for efx_filter_rfs_work()
* @active_queues: Count of RX and TX queues that haven't been flushed and drained.
* @rxq_flush_pending: Count of number of receive queues that need to be flushed.
* Decremented when the efx_flush_rx_queue() is called.
@@ -1004,6 +1027,8 @@ struct efx_nic {
struct mutex rps_mutex;
unsigned int rps_expire_channel;
unsigned int rps_expire_index;
+ unsigned long rps_slot_map;
+ struct efx_async_filter_insertion rps_slot[EFX_RPS_MAX_IN_FLIGHT];
#endif
atomic_t active_queues;
diff --git a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
index 13b0eb71dbf3..9c593c661cbf 100644
--- a/drivers/net/ethernet/sfc/rx.c
+++ b/drivers/net/ethernet/sfc/rx.c
@@ -827,28 +827,13 @@ MODULE_PARM_DESC(rx_refill_threshold,
#ifdef CONFIG_RFS_ACCEL
-/**
- * struct efx_async_filter_insertion - Request to asynchronously insert a filter
- * @net_dev: Reference to the netdevice
- * @spec: The filter to insert
- * @work: Workitem for this request
- * @rxq_index: Identifies the channel for which this request was made
- * @flow_id: Identifies the kernel-side flow for which this request was made
- */
-struct efx_async_filter_insertion {
- struct net_device *net_dev;
- struct efx_filter_spec spec;
- struct work_struct work;
- u16 rxq_index;
- u32 flow_id;
-};
-
static void efx_filter_rfs_work(struct work_struct *data)
{
struct efx_async_filter_insertion *req = container_of(data, struct efx_async_filter_insertion,
work);
struct efx_nic *efx = netdev_priv(req->net_dev);
struct efx_channel *channel = efx_get_channel(efx, req->rxq_index);
+ int slot_idx = req - efx->rps_slot;
int rc;
rc = efx->type->filter_insert(efx, &req->spec, true);
@@ -878,8 +863,8 @@ static void efx_filter_rfs_work(struct work_struct *data)
}
/* Release references */
+ clear_bit(slot_idx, &efx->rps_slot_map);
dev_put(req->net_dev);
- kfree(req);
}
int efx_filter_rfs(struct net_device *net_dev, const struct sk_buff *skb,
@@ -888,22 +873,36 @@ int efx_filter_rfs(struct net_device *net_dev, const struct sk_buff *skb,
struct efx_nic *efx = netdev_priv(net_dev);
struct efx_async_filter_insertion *req;
struct flow_keys fk;
+ int slot_idx;
+ int rc;
- if (flow_id == RPS_FLOW_ID_INVALID)
- return -EINVAL;
+ /* find a free slot */
+ for (slot_idx = 0; slot_idx < EFX_RPS_MAX_IN_FLIGHT; slot_idx++)
+ if (!test_and_set_bit(slot_idx, &efx->rps_slot_map))
+ break;
+ if (slot_idx >= EFX_RPS_MAX_IN_FLIGHT)
+ return -EBUSY;
- if (!skb_flow_dissect_flow_keys(skb, &fk, 0))
- return -EPROTONOSUPPORT;
+ if (flow_id == RPS_FLOW_ID_INVALID) {
+ rc = -EINVAL;
+ goto out_clear;
+ }
- if (fk.basic.n_proto != htons(ETH_P_IP) && fk.basic.n_proto != htons(ETH_P_IPV6))
- return -EPROTONOSUPPORT;
- if (fk.control.flags & FLOW_DIS_IS_FRAGMENT)
- return -EPROTONOSUPPORT;
+ if (!skb_flow_dissect_flow_keys(skb, &fk, 0)) {
+ rc = -EPROTONOSUPPORT;
+ goto out_clear;
+ }
- req = kmalloc(sizeof(*req), GFP_ATOMIC);
- if (!req)
- return -ENOMEM;
+ if (fk.basic.n_proto != htons(ETH_P_IP) && fk.basic.n_proto != htons(ETH_P_IPV6)) {
+ rc = -EPROTONOSUPPORT;
+ goto out_clear;
+ }
+ if (fk.control.flags & FLOW_DIS_IS_FRAGMENT) {
+ rc = -EPROTONOSUPPORT;
+ goto out_clear;
+ }
+ req = efx->rps_slot + slot_idx;
efx_filter_init_rx(&req->spec, EFX_FILTER_PRI_HINT,
efx->rx_scatter ? EFX_FILTER_FLAG_RX_SCATTER : 0,
rxq_index);
@@ -933,6 +932,9 @@ int efx_filter_rfs(struct net_device *net_dev, const struct sk_buff *skb,
req->flow_id = flow_id;
schedule_work(&req->work);
return 0;
+out_clear:
+ clear_bit(slot_idx, &efx->rps_slot_map);
+ return rc;
}
bool __efx_filter_rfs_expire(struct efx_nic *efx, unsigned int quota)
^ permalink raw reply related
* [PATCH net 1/2] sfc: insert ARFS filters with replace_equal=true
From: Edward Cree @ 2018-04-12 14:02 UTC (permalink / raw)
To: linux-net-drivers, David Miller; +Cc: netdev
In-Reply-To: <1713aaa9-2803-0d3b-127a-5240876da7b1@solarflare.com>
Necessary to allow redirecting a flow when the application moves.
Fixes: 3af0f34290f6 ("sfc: replace asynchronous filter operations")
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
drivers/net/ethernet/sfc/rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
index 95682831484e..13b0eb71dbf3 100644
--- a/drivers/net/ethernet/sfc/rx.c
+++ b/drivers/net/ethernet/sfc/rx.c
@@ -851,7 +851,7 @@ static void efx_filter_rfs_work(struct work_struct *data)
struct efx_channel *channel = efx_get_channel(efx, req->rxq_index);
int rc;
- rc = efx->type->filter_insert(efx, &req->spec, false);
+ rc = efx->type->filter_insert(efx, &req->spec, true);
if (rc >= 0) {
/* Remember this so we can check whether to expire the filter
* later.
^ permalink raw reply related
* [PATCH net 0/2] sfc: couple of ARFS fixes
From: Edward Cree @ 2018-04-12 14:00 UTC (permalink / raw)
To: linux-net-drivers, David Miller; +Cc: netdev
Two issues introduced by my recent asynchronous filter handling changes:
1. The old filter_rfs_insert would replace a matching filter of equal
priority; we need to pass the appropriate argument to filter_insert to
make it do the same.
2. It's possible to cause the kernel to hammer ndo_rx_flow_steer very
hard, so make sure we don't build up too huge a backlog of workitems.
Possibly it would be better to fix #2 on the kernel side; I think the way
to do that would be to maintain a forward (as well as reverse) queue-to-
cpu map and replace the set_rps_cpu() check
if (rxq_index == skb_get_rx_queue(skb))
with something like (pseudocode)
if (irqaffinity of queue[skb_get_rx_queue(skb)] includes next_cpu)
but I'm not sure whether it's right or even necessary, and in any case
it's not a regression in 4.17 so isn't 'net' material.
(There's also the issue that we come up in the bad configuration by
default, but that too is a problem for another time.)
Edward Cree (2):
sfc: insert ARFS filters with replace_equal=true
sfc: limit ARFS workitems in flight per channel
drivers/net/ethernet/sfc/net_driver.h | 25 +++++++++++++++
drivers/net/ethernet/sfc/rx.c | 60 ++++++++++++++++++-----------------
2 files changed, 56 insertions(+), 29 deletions(-)
^ permalink raw reply
* Re: [PATCHv2 net] sctp: do not check port in sctp_inet6_cmp_addr
From: Neil Horman @ 2018-04-12 13:58 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Marcelo Ricardo Leitner
In-Reply-To: <7220f314b70726ba4afee91df11e9ae8d1962e01.1523514271.git.lucien.xin@gmail.com>
On Thu, Apr 12, 2018 at 02:24:31PM +0800, Xin Long wrote:
> pf->cmp_addr() is called before binding a v6 address to the sock. It
> should not check ports, like in sctp_inet_cmp_addr.
>
> But sctp_inet6_cmp_addr checks the addr by invoking af(6)->cmp_addr,
> sctp_v6_cmp_addr where it also compares the ports.
>
> This would cause that setsockopt(SCTP_SOCKOPT_BINDX_ADD) could bind
> multiple duplicated IPv6 addresses after Commit 40b4f0fd74e4 ("sctp:
> lack the check for ports in sctp_v6_cmp_addr").
>
> This patch is to remove af->cmp_addr called in sctp_inet6_cmp_addr,
> but do the proper check for both v6 addrs and v4mapped addrs.
>
> v1->v2:
> - define __sctp_v6_cmp_addr to do the common address comparison
> used for both pf and af v6 cmp_addr.
>
> Fixes: 40b4f0fd74e4 ("sctp: lack the check for ports in sctp_v6_cmp_addr")
> Reported-by: Jianwen Ji <jiji@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> net/sctp/ipv6.c | 60 ++++++++++++++++++++++++++++-----------------------------
> 1 file changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
> index f1fc48e..09aba03 100644
> --- a/net/sctp/ipv6.c
> +++ b/net/sctp/ipv6.c
> @@ -521,46 +521,49 @@ static void sctp_v6_to_addr(union sctp_addr *addr, struct in6_addr *saddr,
> addr->v6.sin6_scope_id = 0;
> }
>
> -/* Compare addresses exactly.
> - * v4-mapped-v6 is also in consideration.
> - */
> -static int sctp_v6_cmp_addr(const union sctp_addr *addr1,
> - const union sctp_addr *addr2)
> +static int __sctp_v6_cmp_addr(const union sctp_addr *addr1,
> + const union sctp_addr *addr2)
> {
> if (addr1->sa.sa_family != addr2->sa.sa_family) {
> if (addr1->sa.sa_family == AF_INET &&
> addr2->sa.sa_family == AF_INET6 &&
> - ipv6_addr_v4mapped(&addr2->v6.sin6_addr)) {
> - if (addr2->v6.sin6_port == addr1->v4.sin_port &&
> - addr2->v6.sin6_addr.s6_addr32[3] ==
> - addr1->v4.sin_addr.s_addr)
> - return 1;
> - }
> + ipv6_addr_v4mapped(&addr2->v6.sin6_addr) &&
> + addr2->v6.sin6_addr.s6_addr32[3] ==
> + addr1->v4.sin_addr.s_addr)
> + return 1;
> +
> if (addr2->sa.sa_family == AF_INET &&
> addr1->sa.sa_family == AF_INET6 &&
> - ipv6_addr_v4mapped(&addr1->v6.sin6_addr)) {
> - if (addr1->v6.sin6_port == addr2->v4.sin_port &&
> - addr1->v6.sin6_addr.s6_addr32[3] ==
> - addr2->v4.sin_addr.s_addr)
> - return 1;
> - }
> + ipv6_addr_v4mapped(&addr1->v6.sin6_addr) &&
> + addr1->v6.sin6_addr.s6_addr32[3] ==
> + addr2->v4.sin_addr.s_addr)
> + return 1;
> +
> return 0;
> }
> - if (addr1->v6.sin6_port != addr2->v6.sin6_port)
> - return 0;
> +
> if (!ipv6_addr_equal(&addr1->v6.sin6_addr, &addr2->v6.sin6_addr))
> return 0;
> +
> /* If this is a linklocal address, compare the scope_id. */
> - if (ipv6_addr_type(&addr1->v6.sin6_addr) & IPV6_ADDR_LINKLOCAL) {
> - if (addr1->v6.sin6_scope_id && addr2->v6.sin6_scope_id &&
> - (addr1->v6.sin6_scope_id != addr2->v6.sin6_scope_id)) {
> - return 0;
> - }
> - }
> + if ((ipv6_addr_type(&addr1->v6.sin6_addr) & IPV6_ADDR_LINKLOCAL) &&
> + addr1->v6.sin6_scope_id && addr2->v6.sin6_scope_id &&
> + addr1->v6.sin6_scope_id != addr2->v6.sin6_scope_id)
> + return 0;
>
> return 1;
> }
>
> +/* Compare addresses exactly.
> + * v4-mapped-v6 is also in consideration.
> + */
> +static int sctp_v6_cmp_addr(const union sctp_addr *addr1,
> + const union sctp_addr *addr2)
> +{
> + return __sctp_v6_cmp_addr(addr1, addr2) &&
> + addr1->v6.sin6_port == addr2->v6.sin6_port;
> +}
> +
> /* Initialize addr struct to INADDR_ANY. */
> static void sctp_v6_inaddr_any(union sctp_addr *addr, __be16 port)
> {
> @@ -846,8 +849,8 @@ static int sctp_inet6_cmp_addr(const union sctp_addr *addr1,
> const union sctp_addr *addr2,
> struct sctp_sock *opt)
> {
> - struct sctp_af *af1, *af2;
> struct sock *sk = sctp_opt2sk(opt);
> + struct sctp_af *af1, *af2;
>
> af1 = sctp_get_af_specific(addr1->sa.sa_family);
> af2 = sctp_get_af_specific(addr2->sa.sa_family);
> @@ -863,10 +866,7 @@ static int sctp_inet6_cmp_addr(const union sctp_addr *addr1,
> if (sctp_is_any(sk, addr1) || sctp_is_any(sk, addr2))
> return 1;
>
> - if (addr1->sa.sa_family != addr2->sa.sa_family)
> - return 0;
> -
> - return af1->cmp_addr(addr1, addr2);
> + return __sctp_v6_cmp_addr(addr1, addr2);
> }
>
> /* Verify that the provided sockaddr looks bindable. Common verification,
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* [PATCH 3/4] lan78xx: Read LED modes from Device Tree
From: Phil Elwell @ 2018-04-12 13:55 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, David S. Miller, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Linus Walleij, Andrew Morton, Randy Dunlap,
netdev, devicetree, linux-kernel, linux-usb
Cc: Phil Elwell
In-Reply-To: <1523541336-145953-1-git-send-email-phil@raspberrypi.org>
Add support for DT property "microchip,led-modes", a vector of two
cells (u32s) in the range 0-15, each of which sets the mode for one
of the two LEDs. Some possible values are:
0=link/activity 1=link1000/activity
2=link100/activity 3=link10/activity
4=link100/1000/activity 5=link10/1000/activity
6=link10/100/activity 14=off 15=on
Also use the presence of the DT property to indicate that the
LEDs should be enabled - necessary in the event that no valid OTP
or EEPROM is available.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
---
drivers/net/usb/lan78xx.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index d98397b..ffb483d 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -2008,6 +2008,7 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
{
int ret;
u32 mii_adv;
+ u32 led_modes[2];
struct phy_device *phydev;
phydev = phy_find_first(dev->mdiobus);
@@ -2097,6 +2098,25 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
(void)lan78xx_set_eee(dev->net, &edata);
}
+ if (!of_property_read_u32_array(dev->udev->dev.of_node,
+ "microchip,led-modes",
+ led_modes, ARRAY_SIZE(led_modes))) {
+ u32 reg;
+ int i;
+
+ reg = phy_read(phydev, 0x1d);
+ for (i = 0; i < ARRAY_SIZE(led_modes); i++) {
+ reg &= ~(0xf << (i * 4));
+ reg |= (led_modes[i] & 0xf) << (i * 4);
+ }
+ (void)phy_write(phydev, 0x1d, reg);
+
+ /* Ensure the LEDs are enabled */
+ lan78xx_read_reg(dev, HW_CFG, ®);
+ reg |= HW_CFG_LED0_EN_ | HW_CFG_LED1_EN_;
+ lan78xx_write_reg(dev, HW_CFG, reg);
+ }
+
genphy_config_aneg(phydev);
dev->fc_autoneg = phydev->autoneg;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/4] lan78xx: Read MAC address from DT if present
From: Phil Elwell @ 2018-04-12 13:55 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, David S. Miller, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Linus Walleij, Andrew Morton, Randy Dunlap,
netdev, devicetree, linux-kernel, linux-usb
Cc: Phil Elwell
In-Reply-To: <1523541336-145953-1-git-send-email-phil@raspberrypi.org>
There is a standard mechanism for locating and using a MAC address from
the Device Tree. Use this facility in the lan78xx driver to support
applications without programmed EEPROM or OTP. At the same time,
regularise the handling of the different address sources.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
---
drivers/net/usb/lan78xx.c | 44 +++++++++++++++++++++++---------------------
1 file changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 55a78eb..d2727b5 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -37,6 +37,7 @@
#include <linux/irqchip/chained_irq.h>
#include <linux/microchipphy.h>
#include <linux/phy.h>
+#include <linux/of_net.h>
#include "lan78xx.h"
#define DRIVER_AUTHOR "WOOJUNG HUH <woojung.huh@microchip.com>"
@@ -1651,34 +1652,35 @@ static void lan78xx_init_mac_address(struct lan78xx_net *dev)
addr[5] = (addr_hi >> 8) & 0xFF;
if (!is_valid_ether_addr(addr)) {
- /* reading mac address from EEPROM or OTP */
- if ((lan78xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
- addr) == 0) ||
- (lan78xx_read_otp(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
- addr) == 0)) {
- if (is_valid_ether_addr(addr)) {
- /* eeprom values are valid so use them */
- netif_dbg(dev, ifup, dev->net,
- "MAC address read from EEPROM");
- } else {
- /* generate random MAC */
- random_ether_addr(addr);
- netif_dbg(dev, ifup, dev->net,
- "MAC address set to random addr");
- }
+ const u8 *mac_addr;
- addr_lo = addr[0] | (addr[1] << 8) |
- (addr[2] << 16) | (addr[3] << 24);
- addr_hi = addr[4] | (addr[5] << 8);
-
- ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
- ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
+ mac_addr = of_get_mac_address(dev->udev->dev.of_node);
+ if (mac_addr) {
+ /* valid address present in Device Tree */
+ ether_addr_copy(addr, mac_addr);
+ netif_dbg(dev, ifup, dev->net,
+ "MAC address read from Device Tree");
+ } else if (((lan78xx_read_eeprom(dev, EEPROM_MAC_OFFSET,
+ ETH_ALEN, addr) == 0) ||
+ (lan78xx_read_otp(dev, EEPROM_MAC_OFFSET,
+ ETH_ALEN, addr) == 0)) &&
+ is_valid_ether_addr(addr)) {
+ /* eeprom values are valid so use them */
+ netif_dbg(dev, ifup, dev->net,
+ "MAC address read from EEPROM");
} else {
/* generate random MAC */
random_ether_addr(addr);
netif_dbg(dev, ifup, dev->net,
"MAC address set to random addr");
}
+
+ addr_lo = addr[0] | (addr[1] << 8) |
+ (addr[2] << 16) | (addr[3] << 24);
+ addr_hi = addr[4] | (addr[5] << 8);
+
+ ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
+ ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
}
ret = lan78xx_write_reg(dev, MAF_LO(0), addr_lo);
--
2.7.4
^ permalink raw reply related
* [PATCH 4/4] dt-bindings: Document the DT bindings for lan78xx
From: Phil Elwell @ 2018-04-12 13:55 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, David S. Miller, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Linus Walleij, Andrew Morton, Randy Dunlap,
netdev, devicetree, linux-kernel, linux-usb
Cc: Phil Elwell
In-Reply-To: <1523541336-145953-1-git-send-email-phil@raspberrypi.org>
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
Document the supported properties in a bindings file, adding it to
MAINTAINERS at the same time.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
---
.../devicetree/bindings/net/microchip,lan78xx.txt | 44 ++++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/microchip,lan78xx.txt
diff --git a/Documentation/devicetree/bindings/net/microchip,lan78xx.txt b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
new file mode 100644
index 0000000..e7d7850
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
@@ -0,0 +1,44 @@
+Microchip LAN78xx Gigabit Ethernet controller
+
+The LAN78XX devices are usually configured by programming their OTP or with
+an external EEPROM, but some platforms (e.g. Raspberry Pi 3 B+) have neither.
+
+Please refer to ethernet.txt for a description of common Ethernet bindings.
+
+Optional properties:
+- microchip,eee-enabled: if present, enable Energy Efficient Ethernet support;
+- microchip,led-modes: a two-element vector, with each element configuring
+ the operating mode of an LED. The values supported by the device are;
+ 0: Link/Activity
+ 1: Link1000/Activity
+ 2: Link100/Activity
+ 3: Link10/Activity
+ 4: Link100/1000/Activity
+ 5: Link10/1000/Activity
+ 6: Link10/100/Activity
+ 7: RESERVED
+ 8: Duplex/Collision
+ 9: Collision
+ 10: Activity
+ 11: RESERVED
+ 12: Auto-negotiation Fault
+ 13: RESERVED
+ 14: Off
+ 15: On
+- microchip,tx-lpi-timer: the delay (in microseconds) between the TX fifo
+ becoming empty and invoking Low Power Idles (default 600).
+
+Example:
+
+ /* Standard configuration for a Raspberry Pi 3 B+ */
+ ethernet: usbether@1 {
+ compatible = "usb424,7800";
+ reg = <1>;
+ microchip,eee-enabled;
+ microchip,tx-lpi-timer = <600>;
+ /*
+ * led0 = 1:link1000/activity
+ * led1 = 6:link10/100/activity
+ */
+ microchip,led-modes = <1 6>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 2328eed..b637aad 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14482,6 +14482,7 @@ M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/usb/lan78xx.*
+F: Documentation/devicetree/bindings/net/microchip,lan78xx.txt
USB MASS STORAGE DRIVER
M: Alan Stern <stern@rowland.harvard.edu>
--
2.7.4
^ permalink raw reply related
* [PATCH 2/4] lan78xx: Read initial EEE setting from Device Tree
From: Phil Elwell @ 2018-04-12 13:55 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, David S. Miller, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Linus Walleij, Andrew Morton, Randy Dunlap,
netdev, devicetree, linux-kernel, linux-usb
Cc: Phil Elwell
In-Reply-To: <1523541336-145953-1-git-send-email-phil@raspberrypi.org>
Add two new Device Tree properties:
* microchip,eee-enabled - a boolean to enable EEE
* microchip,tx-lpi-timer - time in microseconds to wait after TX goes
idle before entering the low power state
(default 600)
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
---
drivers/net/usb/lan78xx.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index d2727b5..d98397b 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -2080,6 +2080,23 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
mii_adv = (u32)mii_advertise_flowctrl(dev->fc_request_control);
phydev->advertising |= mii_adv_to_ethtool_adv_t(mii_adv);
+ if (of_property_read_bool(dev->udev->dev.of_node,
+ "microchip,eee-enabled")) {
+ struct ethtool_eee edata;
+
+ memset(&edata, 0, sizeof(edata));
+ edata.cmd = ETHTOOL_SEEE;
+ edata.advertised = ADVERTISED_1000baseT_Full |
+ ADVERTISED_100baseT_Full;
+ edata.eee_enabled = true;
+ edata.tx_lpi_enabled = true;
+ if (of_property_read_u32(dev->udev->dev.of_node,
+ "microchip,tx-lpi-timer",
+ &edata.tx_lpi_timer))
+ edata.tx_lpi_timer = 600; /* non-aggressive */
+ (void)lan78xx_set_eee(dev->net, &edata);
+ }
+
genphy_config_aneg(phydev);
dev->fc_autoneg = phydev->autoneg;
--
2.7.4
^ permalink raw reply related
* [PATCH 0/4] lan78xx: Read configuration from Device Tree
From: Phil Elwell @ 2018-04-12 13:55 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, David S. Miller, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Linus Walleij, Andrew Morton, Randy Dunlap,
netdev, devicetree, linux-kernel, linux-usb
Cc: Phil Elwell
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
This patch set adds support for reading the MAC address, EEE setting
and LED modes from Device Tree.
Phil Elwell (4):
lan78xx: Read MAC address from DT if present
lan78xx: Read initial EEE setting from Device Tree
lan78xx: Read LED modes from Device Tree
dt-bindings: Document the DT bindings for lan78xx
.../devicetree/bindings/net/microchip,lan78xx.txt | 44 ++++++++++++
MAINTAINERS | 1 +
drivers/net/usb/lan78xx.c | 81 ++++++++++++++++------
3 files changed, 105 insertions(+), 21 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/microchip,lan78xx.txt
--
2.7.4
^ permalink raw reply
* XDP performance regression due to CONFIG_RETPOLINE Spectre V2
From: Jesper Dangaard Brouer @ 2018-04-12 13:50 UTC (permalink / raw)
To: xdp-newbies@vger.kernel.org, netdev@vger.kernel.org
Cc: brouer, Christoph Hellwig, David Woodhouse, William Tu,
Björn Töpel, Karlsson, Magnus, Alexander Duyck,
Arnaldo Carvalho de Melo
Heads-up XDP performance nerds!
I got an unpleasant surprise when I updated my GCC compiler (to support
the option -mindirect-branch=thunk-extern). My XDP redirect
performance numbers when cut in half; from approx 13Mpps to 6Mpps
(single CPU core). I've identified the issue, which is caused by
kernel CONFIG_RETPOLINE, that only have effect when the GCC compiler
have support. This is mitigation of Spectre variant 2 (CVE-2017-5715)
related to indirect (function call) branches.
XDP_REDIRECT itself only have two primary (per packet) indirect
function calls, ndo_xdp_xmit and invoking bpf_prog, plus any
map_lookup_elem calls in the bpf_prog. I PoC implemented bulking for
ndo_xdp_xmit, which helped, but not enough. The real root-cause is all
the DMA API calls, which uses function pointers extensively.
Mitigation plan
---------------
Implement support for keeping the DMA mapping through the XDP return
call, to remove RX map/unmap calls. Implement bulking for XDP
ndo_xdp_xmit and XDP return frame API. Bulking allows to perform DMA
bulking via scatter-gatter DMA calls, XDP TX need it for DMA
map+unmap. The driver RX DMA-sync (to CPU) per packet calls are harder
to mitigate (via bulk technique). Ask DMA maintainer for a common
case direct call for swiotlb DMA sync call ;-)
Root-cause verification
-----------------------
I have verified that indirect DMA calls are the root-cause, by
removing the DMA sync calls from the code (as they for swiotlb does
nothing), and manually inlined the DMA map calls (basically calling
phys_to_dma(dev, page_to_phys(page)) + offset). For my ixgbe test,
performance "returned" to 11Mpps.
Perf reports
------------
It is not easy to diagnose via perf event tool. I'm coordinating with
ACME to make it easier to pinpoint the hotspots. Lookout for symbols:
__x86_indirect_thunk_r10, __indirect_thunk_start, __x86_indirect_thunk_rdx
etc. Be aware that they might not be super high in perf top, but they
stop CPU speculation. Thus, instead use perf-stat and see the
negative effect of 'insn per cycle'.
Want to understand retpoline at ASM level read this:
https://support.google.com/faqs/answer/7625886
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [bpf-next PATCH 1/4] bpf: sockmap, free memory on sock close with cork data
From: Simon Horman @ 2018-04-12 13:13 UTC (permalink / raw)
To: John Fastabend; +Cc: ast, daniel, netdev, davem
In-Reply-To: <20180401150054.24727.78359.stgit@john-Precision-Tower-5810>
On Sun, Apr 01, 2018 at 08:00:54AM -0700, John Fastabend wrote:
> If a socket with pending cork data is closed we do not return the
> memory to the socket until the garbage collector free's the psock
> structure. The garbage collector though can run after the sock has
> completed its close operation. If this ordering happens the sock code
> will through a WARN_ON because there is still outstanding memory
s/through/throw/ ?
> accounted to the sock.
>
> To resolve this ensure we return memory to the sock when a socket
> is closed.
>
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
> Fixes: 91843d540a13 ("bpf: sockmap, add msg_cork_bytes() helper")
> ---
> kernel/bpf/sockmap.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
> index d2bda5a..8ddf326 100644
> --- a/kernel/bpf/sockmap.c
> +++ b/kernel/bpf/sockmap.c
> @@ -211,6 +211,12 @@ static void bpf_tcp_close(struct sock *sk, long timeout)
> close_fun = psock->save_close;
>
> write_lock_bh(&sk->sk_callback_lock);
> + if (psock->cork) {
> + free_start_sg(psock->sock, psock->cork);
> + kfree(psock->cork);
> + psock->cork = NULL;
> + }
> +
> list_for_each_entry_safe(md, mtmp, &psock->ingress, list) {
> list_del(&md->list);
> free_start_sg(psock->sock, md);
>
^ permalink raw reply
* Re: iproute2-4.16.0 no longer accepts routes via fe80::1
From: Thomas Deutschmann @ 2018-04-12 12:41 UTC (permalink / raw)
To: netdev; +Cc: serhe.popovych
In-Reply-To: <53f39aca-b0ac-79a4-3427-175598b17037@gentoo.org>
Hi,
well, it isn't just "fe80::1", it is any IPv6 address which
will be rejected if not called with "-6". I run bisect:
> git bisect start
> # good: [50b8a842e8c098cddb213f5b3076526df88826e8] v4.15.0
> git bisect good 50b8a842e8c098cddb213f5b3076526df88826e8
> # bad: [4b6c4177ee66421770f0bbcc765c29135e44d921] v4.16.0
> git bisect bad 4b6c4177ee66421770f0bbcc765c29135e44d921
> # bad: [5f4892e2c8d4fb22118713e0c83290b352fe0e34] rdma: Make visible the number of arguments
> git bisect bad 5f4892e2c8d4fb22118713e0c83290b352fe0e34
> # good: [8c75f69411bc8c3affe5d173afcf981d15f5da15] Merge branch 'master' into net-next
> git bisect good 8c75f69411bc8c3affe5d173afcf981d15f5da15
> # bad: [27c523e209ab956ff269afec68c6e744e7f5edb6] utils: Introduce get_addr_rta() and inet_addr_match_rta()
> git bisect bad 27c523e209ab956ff269afec68c6e744e7f5edb6
> # bad: [d0bcedd549566a87354aa804df3be6be80681ee9] tc: introduce tc_qdisc_block_exists helper
> git bisect bad d0bcedd549566a87354aa804df3be6be80681ee9
> # bad: [6c4b672738acf680ee98c10e79a52a8dede5f9a6] iplink_geneve: Get rid of inet_get_addr()
> git bisect bad 6c4b672738acf680ee98c10e79a52a8dede5f9a6
> # bad: [93fa12418dc6f5943692250244be303bb162175b] utils: Always specify family and ->bytelen in get_prefix_1()
> git bisect bad 93fa12418dc6f5943692250244be303bb162175b
> # good: [f2522007d8fee924cb098b4afc8af16f2b25829f] utils: Always specify family for address in get_addr_1()
> git bisect good f2522007d8fee924cb098b4afc8af16f2b25829f
> # first bad commit: [93fa12418dc6f5943692250244be303bb162175b] utils: Always specify family and ->bytelen in get_prefix_1()
> From 93fa12418dc6f5943692250244be303bb162175b Mon Sep 17 00:00:00 2001
> From: Serhey Popovych
> Date: Thu, 18 Jan 2018 20:13:43 +0200
> Subject: utils: Always specify family and ->bytelen in get_prefix_1()
>
> Handle default/all/any special case in get_addr_1() to setup
> ->family and ->bytelen correctly.
>
> Make get_addr_1() return ->bitlen == -2 instead of -1 to
> distinguish default/all/any special case from the rest:
> it is safe because all callers check ->bitlen < 0, not
> explicit value -1.
>
> Reduce intendation by one level and get rid of goto/label
> to make code more readable.
>
> Signed-off-by: Serhey Popovych
> Signed-off-by: David Ahern
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=93fa12418dc6f5943692250244be303bb162175b
So was this an intended behavior change? I.e. this will require
updates for various user space tools/network configuration scripts
which are relying on ip utilities feature to auto-detect inet family
which was "supported" (at least working) until 4.16.0...
--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
^ permalink raw reply
* Re: net: hang in unregister_netdevice: waiting for lo to become free
From: Dmitry Vyukov @ 2018-04-12 12:15 UTC (permalink / raw)
To: Tommi Rantala
Cc: Neil Horman, Xin Long, David Ahern, Daniel Borkmann, Cong Wang,
David Miller, Eric Dumazet, Willem de Bruijn, Jakub Kicinski,
Rasmus Villemoes, netdev, LKML, Alexey Kuznetsov,
Hideaki YOSHIFUJI, syzkaller, Dan Streetman, Eric W. Biederman,
Alexey Kodanev, Marcelo Ricardo Leitner
In-Reply-To: <7d98027d-e810-a079-49c5-0bf8beef390e@nokia.com>
On Wed, Feb 21, 2018 at 3:53 PM, Tommi Rantala
<tommi.t.rantala@nokia.com> wrote:
> On 20.02.2018 18:26, Neil Horman wrote:
>>
>> On Tue, Feb 20, 2018 at 09:14:41AM +0100, Dmitry Vyukov wrote:
>>>
>>> On Tue, Feb 20, 2018 at 8:56 AM, Tommi Rantala
>>> <tommi.t.rantala@nokia.com> wrote:
>>>>
>>>> On 19.02.2018 20:59, Dmitry Vyukov wrote:
>>>>>
>>>>> Is this meant to be fixed already? I am still seeing this on the
>>>>> latest upstream tree.
>>>>>
>>>>
>>>> These two commits are in v4.16-rc1:
>>>>
>>>> commit 4a31a6b19f9ddf498c81f5c9b089742b7472a6f8
>>>> Author: Tommi Rantala <tommi.t.rantala@nokia.com>
>>>> Date: Mon Feb 5 21:48:14 2018 +0200
>>>>
>>>> sctp: fix dst refcnt leak in sctp_v4_get_dst
>>>> ...
>>>> Fixes: 410f03831 ("sctp: add routing output fallback")
>>>> Fixes: 0ca50d12f ("sctp: fix src address selection if using
>>>> secondary
>>>> addresses")
>>>>
>>>>
>>>> commit 957d761cf91cdbb175ad7d8f5472336a4d54dbf2
>>>> Author: Alexey Kodanev <alexey.kodanev@oracle.com>
>>>> Date: Mon Feb 5 15:10:35 2018 +0300
>>>>
>>>> sctp: fix dst refcnt leak in sctp_v6_get_dst()
>>>> ...
>>>> Fixes: dbc2b5e9a09e ("sctp: fix src address selection if using
>>>> secondary
>>>> addresses for ipv6")
>>>>
>>>>
>>>> I guess we missed something if it's still reproducible.
>>>>
>>>> I can check it later this week, unless someone else beat me to it.
>>>
>>>
>>> Hi Tommi,
>>>
>>> Hmmm, I can't claim that it's exactly the same bug. Perhaps it's
>>> another one then. But I am still seeing these:
>>>
>>> [ 58.799130] unregister_netdevice: waiting for lo to become free.
>>> Usage count = 4
>>> [ 60.847138] unregister_netdevice: waiting for lo to become free.
>>> Usage count = 4
>>> [ 62.895093] unregister_netdevice: waiting for lo to become free.
>>> Usage count = 4
>>> [ 64.943103] unregister_netdevice: waiting for lo to become free.
>>> Usage count = 4
>>>
>>> on upstream tree pulled ~12 hours ago.
>>>
>> Can you write a systemtap script to probe dev_hold, and dev_put, printing
>> out a
>> backtrace if the device name matches "lo". That should tell us
>> definitively if
>> the problem is in the same location or not
>
>
> Hi Dmitry, I tested with the reproducer and the kernel .config file that you
> sent in the first email in this thread:
>
> With 4.16-rc2 unable to reproduce.
>
> With 4.15-rc9 bug reproducible, and I get "unregister_netdevice: waiting for
> lo to become free. Usage count = 3"
>
> With 4.15-rc9 and Alexey's "sctp: fix dst refcnt leak in sctp_v6_get_dst()"
> cherry-picked on top, unable to reproduce.
>
>
> Is syzkaller doing something else now to trigger the bug...?
> Can you still trigger the bug with the same reproducer?
Hi Neil, Tommi,
Reviving this old thread about "unregister_netdevice: waiting for lo
to become free. Usage count = 3" hangs.
I still did not have time to deep dive into what happens there (too
many bugs coming from syzbot). But this still actively happens and I
suspect accounts to a significant portion of various hang reports,
which are quite unpleasant.
One idea that could make it all simpler:
Is this wait loop in netdev_wait_allrefs() supposed to wait for any
prolonged periods of time under any non-buggy conditions? E.g. more
than 1-2 minutes?
If it only supposed to wait briefly for things that already supposed
to be shutting down, and we add a WARNING there after some timeout,
then syzbot will report all info how/when it happens, hopefully
extracting reproducers, and all the nice things.
But this WARNING should not have any false positives under any
realistic conditions (e.g. waiting for arrival of remote packets with
large timeouts).
Looking at some task hung reports, it seems that this code holds some
mutexes, takes workqueue thread and prevents any progress with
destruction of other devices (and net namespace creation/destruction),
so I guess it should not wait for any indefinite periods of time?
^ permalink raw reply
* Re: [PATCH] net: ieee802154: atusb: Replace GFP_ATOMIC with GFP_KERNEL in atusb_probe
From: Stefan Schmidt @ 2018-04-12 12:08 UTC (permalink / raw)
To: Jia-Ju Bai, alex.aring; +Cc: linux-wpan, netdev, linux-kernel
In-Reply-To: <1523412850-2260-1-git-send-email-baijiaju1990@gmail.com>
Hello.
On 04/11/2018 04:14 AM, Jia-Ju Bai wrote:
> atusb_probe() is never called in atomic context.
> This function is only set as ".probe" in struct usb_driver.
>
> Despite never getting called from atomic context,
> atusb_probe() calls usb_alloc_urb() with GFP_ATOMIC,
> which does not sleep for allocation.
> GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
> which can sleep and improve the possibility of sucessful allocation.
>
> This is found by a static analysis tool named DCNS written by myself.
> And I also manually check it.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
> ---
> drivers/net/ieee802154/atusb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c
> index ef68851..ab6a505 100644
> --- a/drivers/net/ieee802154/atusb.c
> +++ b/drivers/net/ieee802154/atusb.c
> @@ -789,7 +789,7 @@ static int atusb_probe(struct usb_interface *interface,
> atusb->tx_dr.bRequest = ATUSB_TX;
> atusb->tx_dr.wValue = cpu_to_le16(0);
>
> - atusb->tx_urb = usb_alloc_urb(0, GFP_ATOMIC);
> + atusb->tx_urb = usb_alloc_urb(0, GFP_KERNEL);
> if (!atusb->tx_urb)
> goto fail;
>
This patch has been applied to the wpan tree and will be
part of the next pull request to net. Thanks!
regards
Stefan Schmidt
^ permalink raw reply
* RE: [RFC PATCH v2 14/14] samples/bpf: sample application for AF_XDP sockets
From: Karlsson, Magnus @ 2018-04-12 11:08 UTC (permalink / raw)
To: Jesper Dangaard Brouer, Björn Töpel
Cc: Duyck, Alexander H, alexander.duyck@gmail.com,
john.fastabend@gmail.com, ast@fb.com,
willemdebruijn.kernel@gmail.com, daniel@iogearbox.net,
netdev@vger.kernel.org, michael.lundkvist@ericsson.com,
Brandeburg, Jesse, Singhai, Anjali, Zhang, Qi Z,
ravineet.singh@ericsson.com, Topel, Bjorn
In-Reply-To: <20180412130521.30d41cbc@redhat.com>
> -----Original Message-----
> From: Jesper Dangaard Brouer [mailto:brouer@redhat.com]
> Sent: Thursday, April 12, 2018 1:05 PM
> To: Björn Töpel <bjorn.topel@gmail.com>
> Cc: Karlsson, Magnus <magnus.karlsson@intel.com>; Duyck, Alexander H
> <alexander.h.duyck@intel.com>; alexander.duyck@gmail.com;
> john.fastabend@gmail.com; ast@fb.com;
> willemdebruijn.kernel@gmail.com; daniel@iogearbox.net;
> netdev@vger.kernel.org; michael.lundkvist@ericsson.com; Brandeburg,
> Jesse <jesse.brandeburg@intel.com>; Singhai, Anjali
> <anjali.singhai@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
> ravineet.singh@ericsson.com; Topel, Bjorn <bjorn.topel@intel.com>;
> brouer@redhat.com
> Subject: Re: [RFC PATCH v2 14/14] samples/bpf: sample application for
> AF_XDP sockets
>
> On Tue, 27 Mar 2018 18:59:19 +0200
> Björn Töpel <bjorn.topel@gmail.com> wrote:
>
> > +static void dump_stats(void)
> > +{
> > + unsigned long stop_time = get_nsecs();
> > + long dt = stop_time - start_time;
> > + int i;
> > +
> > + for (i = 0; i < num_socks; i++) {
> > + double rx_pps = xsks[i]->rx_npkts * 1000000000.
> / dt;
> > + double tx_pps = xsks[i]->tx_npkts * 1000000000.
> / dt;
> > + char *fmt = "%-15s %'-11.0f %'-11lu\n";
> > +
> > + printf("\n sock%d@", i);
> > + print_benchmark(false);
> > + printf("\n");
> > +
> > + printf("%-15s %-11s %-11s %-11.2f\n", "", "pps",
> "pkts",
> > + dt / 1000000000.);
> > + printf(fmt, "rx", rx_pps, xsks[i]->rx_npkts);
> > + printf(fmt, "tx", tx_pps, xsks[i]->tx_npkts);
> > + }
> > +}
> > +
> > +static void *poller(void *arg)
> > +{
> > + (void)arg;
> > + for (;;) {
> > + sleep(1);
> > + dump_stats();
> > + }
> > +
> > + return NULL;
> > +}
>
> You are printing the "pps" (packets per sec) as an average over the entire
> test run... could you please change that to, at least also, have an more up-to-
> date value like between the last measurement?
>
> The problem is that when you start the test, the first reading will be too low,
> and it takes time to average out/up. For ixgbe, first reading will be zero,
> because it does a link-down+up, which stops my pktgen.
>
> The second annoyance is that I like to change system/kernel setting during
> the run, and observe the effect. E.g change CPU sleep states (via tuned-
> adm) during the test-run to see the effect, which I cannot with this long
> average.
Good points. Will fix.
/Magnus
>
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Principal Kernel Engineer at Red Hat
> LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [RFC PATCH v2 14/14] samples/bpf: sample application for AF_XDP sockets
From: Jesper Dangaard Brouer @ 2018-04-12 11:05 UTC (permalink / raw)
To: Björn Töpel
Cc: magnus.karlsson, alexander.h.duyck, alexander.duyck,
john.fastabend, ast, willemdebruijn.kernel, daniel, netdev,
michael.lundkvist, jesse.brandeburg, anjali.singhai, qi.z.zhang,
ravineet.singh, Björn Töpel, brouer
In-Reply-To: <20180327165919.17933-15-bjorn.topel@gmail.com>
On Tue, 27 Mar 2018 18:59:19 +0200
Björn Töpel <bjorn.topel@gmail.com> wrote:
> +static void dump_stats(void)
> +{
> + unsigned long stop_time = get_nsecs();
> + long dt = stop_time - start_time;
> + int i;
> +
> + for (i = 0; i < num_socks; i++) {
> + double rx_pps = xsks[i]->rx_npkts * 1000000000. / dt;
> + double tx_pps = xsks[i]->tx_npkts * 1000000000. / dt;
> + char *fmt = "%-15s %'-11.0f %'-11lu\n";
> +
> + printf("\n sock%d@", i);
> + print_benchmark(false);
> + printf("\n");
> +
> + printf("%-15s %-11s %-11s %-11.2f\n", "", "pps", "pkts",
> + dt / 1000000000.);
> + printf(fmt, "rx", rx_pps, xsks[i]->rx_npkts);
> + printf(fmt, "tx", tx_pps, xsks[i]->tx_npkts);
> + }
> +}
> +
> +static void *poller(void *arg)
> +{
> + (void)arg;
> + for (;;) {
> + sleep(1);
> + dump_stats();
> + }
> +
> + return NULL;
> +}
You are printing the "pps" (packets per sec) as an average over the
entire test run... could you please change that to, at least also, have
an more up-to-date value like between the last measurement?
The problem is that when you start the test, the first reading will be
too low, and it takes time to average out/up. For ixgbe, first reading
will be zero, because it does a link-down+up, which stops my pktgen.
The second annoyance is that I like to change system/kernel setting
during the run, and observe the effect. E.g change CPU sleep states
(via tuned-adm) during the test-run to see the effect, which I cannot
with this long average.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox