* [PATCH v5 1/3] Documentation: dt: net: Add binding doc for Keystone NetCP ethernet driver
From: Santosh Shilimkar @ 2014-09-25 17:48 UTC (permalink / raw)
To: davem, netdev
Cc: linux-arm-kernel, linux-kernel, robh+dt, grant.likely, devicetree,
sandeep_n, joe, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Santosh Shilimkar
In-Reply-To: <1411667317-1163-1-git-send-email-santosh.shilimkar@ti.com>
From: Sandeep Nair <sandeep_n@ti.com>
The network coprocessor (NetCP) is a hardware accelerator that processes
Ethernet packets. NetCP has a gigabit Ethernet (GbE) subsystem with a ethernet
switch sub-module to send and receive packets. NetCP also includes a packet
accelerator (PA) module to perform packet classification operations such as
header matching, and packet modification operations such as checksum
generation. NetCP can also optionally include a Security Accelerator(SA)
capable of performing IPSec operations on ingress/egress packets.
Keystone SoC's also have a 10 Gigabit Ethernet Subsystem (XGbE) which
includes a 3-port Ethernet switch sub-module capable of 10Gb/s and
1Gb/s rates per Ethernet port.
NetCP Subsystem device tree layout looks something like below:
-----------------------------
NetCP subsystem(10G or 1G)
-----------------------------
|
|-> NetCP Devices -> |
| |-> GBE/XGBE Switch
| |
| |-> Packet Accelerator
| |
| |-> Security Accelerator
|
|
|
|-> NetCP Interfaces -> |
|-> Ethernet Port 0
|
|-> Ethernet Port 1
|
|-> Ethernet Port 2
|
|-> Ethernet Port 3
Common driver supports GBE as well XGBE network processors.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Sandeep Nair <sandeep_n@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
.../devicetree/bindings/net/keystone-netcp.txt | 197 ++++++++++++++++++++
1 file changed, 197 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/keystone-netcp.txt
diff --git a/Documentation/devicetree/bindings/net/keystone-netcp.txt b/Documentation/devicetree/bindings/net/keystone-netcp.txt
new file mode 100644
index 0000000..a7d061b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/keystone-netcp.txt
@@ -0,0 +1,197 @@
+This document describes the device tree bindings associated with the
+keystone network coprocessor(NetCP) driver support.
+
+The network coprocessor (NetCP) is a hardware accelerator that processes
+Ethernet packets. NetCP has a gigabit Ethernet (GbE) subsytem with a ethernet
+switch sub-module to send and receive packets. NetCP also includes a packet
+accelerator (PA) module to perform packet classification operations such as
+header matching, and packet modification operations such as checksum
+generation. NetCP can also optionally include a Security Accelerator (SA)
+capable of performing IPSec operations on ingress/egress packets.
+
+Keystone II SoC's also have a 10 Gigabit Ethernet Subsystem (XGbE) which
+includes a 3-port Ethernet switch sub-module capable of 10Gb/s and 1Gb/s rates
+per Ethernet port.
+
+Keystone NetCP driver has a plug-in module architecture where each of the NetCP
+sub-modules exist as a loadable kernel module which plug in to the netcp core.
+These sub-modules are represented as "netcp-devices" in the dts bindings. It is
+mandatory to have the ethernet switch sub-module for the ethernet interface to
+be operational. Any other sub-module like the PA is optional.
+
+NetCP Ethernet SubSystem Layout:
+
+-----------------------------
+ NetCP subsystem(10G or 1G)
+-----------------------------
+ |
+ |-> NetCP Devices -> |
+ | |-> GBE/XGBE Switch
+ | |
+ | |-> Packet Accelerator
+ | |
+ | |-> Security Accelerator
+ |
+ |
+ |
+ |-> NetCP Interfaces -> |
+ |-> Ethernet Port 0
+ |
+ |-> Ethernet Port 1
+ |
+ |-> Ethernet Port 2
+ |
+ |-> Ethernet Port 3
+
+
+NetCP subsystem properties:
+Required properties:
+- compatible: Should be "ti,netcp-1.0"
+- clocks: phandle to the reference clocks for the subsystem.
+- dma-id: Navigator packet dma instance id.
+
+Optional properties:
+- reg: register location and the size for the following register
+ regions in the specified order.
+ - Efuse MAC address register
+- dma-coherent: Present if dma operations are coherent
+- big-endian: Keystone devices can be operated in a mode where the DSP is in
+ the big endian mode. In such cases enable this option. This
+ option should also be enabled if the ARM is operated in
+ big endian mode with the DSP in little endian.
+
+NetCP device properties: Device specification for NetCP sub-modules.
+1Gb/10Gb (gbe/xgbe) ethernet switch sub-module specifications.
+Required properties:
+- label: Must be "netcp-gbe" for 1Gb & "netcp-xgbe" for 10Gb.
+- reg: register location and the size for the following register
+ regions in the specified order.
+ - subsystem registers
+ - serdes registers
+- tx-channel: the navigator packet dma channel number for tx.
+- tx-queue: the navigator queue number associated with the tx dma channel.
+- interfaces: specification for each of the switch port to be registered as a
+ network interface in the stack.
+-- slave-port: Switch port number, 0 based numbering.
+-- link-interface: type of link interface, supported options are
+ - mac<->mac auto negotiate mode: 0
+ - mac<->phy mode: 1
+ - mac<->mac forced mode: 2
+ - mac<->fiber mode: 3
+ - mac<->phy mode with no mdio: 4
+ - 10Gb mac<->phy mode : 10
+ - 10Gb mac<->mac forced mode : 11
+----phy-handle: phandle to PHY device
+
+Optional properties:
+- enable-ale: NetCP driver keeps the address learning feature in the ethernet
+ switch module disabled. This attribute is to enable the address
+ learning.
+- secondary-slave-ports: specification for each of the switch port not be
+ registered as a network interface. NetCP driver
+ will only initialize these ports and attach PHY
+ driver to them if needed.
+
+NetCP interface properties: Interface specification for NetCP sub-modules.
+Required properties:
+- rx-channel: the navigator packet dma channel number for rx.
+- rx-queue: the navigator queue number associated with rx dma channel.
+- rx-pool: specifies the number of descriptors to be used & the region-id
+ for creating the rx descriptor pool.
+- tx-pool: specifies the number of descriptors to be used & the region-id
+ for creating the tx descriptor pool.
+- rx-queue-depth: number of descriptors in each of the free descriptor
+ queue (FDQ) for the pktdma Rx flow. There can be at
+ present a maximum of 4 queues per Rx flow.
+- rx-buffer-size: the buffer size for each of the Rx flow FDQ.
+- tx-completion-queue: the navigator queue number where the descriptors are
+ recycled after Tx DMA completion.
+
+Optional properties:
+- efuse-mac: If this is 1, then the MAC address for the interface is
+ obtained from the device efuse mac address register
+- local-mac-address: the driver is designed to use the of_get_mac_address api
+ only if efuse-mac is 0. When efuse-mac is 0, the MAC
+ address is obtained from local-mac-address. If this
+ attribute is not present, then the driver will use a
+ random MAC address.
+- "netcp-device label": phandle to the device specification for each of NetCP
+ sub-module attached to this interface.
+
+Example binding:
+
+netcp: netcp@2090000 {
+ reg = <0x2620110 0x8>;
+ reg-names = "efuse";
+ compatible = "ti,netcp-1.0";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ clocks = <&papllclk>, <&clkcpgmac>, <&chipclk12>;
+ dma-coherent;
+ /* big-endian; */
+ dma-id = <0>;
+
+ netcp-devices {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ gbe@0x2090000 {
+ label = "netcp-gbe";
+ reg = <0x2090000 0xf00>;
+ /* enable-ale; */
+ tx-queue = <648>;
+ tx-channel = <8>;
+
+ interfaces {
+ gbe0: interface-0 {
+ slave-port = <0>;
+ link-interface = <4>;
+ };
+ gbe1: interface-1 {
+ slave-port = <1>;
+ link-interface = <4>;
+ };
+ };
+
+ secondary-slave-ports {
+ port-2 {
+ slave-port = <2>;
+ link-interface = <2>;
+ };
+ port-3 {
+ slave-port = <3>;
+ link-interface = <2>;
+ };
+ };
+ };
+ };
+
+ netcp-interfaces {
+ interface-0 {
+ rx-channel = <22>;
+ rx-pool = <1024 12>;
+ tx-pool = <1024 12>;
+ rx-queue-depth = <128 128 0 0>;
+ rx-buffer-size = <1518 4096 0 0>;
+ rx-queue = <8704>;
+ tx-completion-queue = <8706>;
+ efuse-mac = <1>;
+ netcp-gbe = <&gbe0>;
+
+ };
+ interface-1 {
+ rx-channel = <23>;
+ rx-pool = <1024 12>;
+ tx-pool = <1024 12>;
+ rx-queue-depth = <128 128 0 0>;
+ rx-buffer-size = <1518 4096 0 0>;
+ rx-queue = <8705>;
+ tx-completion-queue = <8707>;
+ efuse-mac = <0>;
+ local-mac-address = [02 18 31 7e 3e 6f];
+ netcp-gbe = <&gbe1>;
+ };
+ };
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 0/3] net: Add Keystone NetCP ethernet driver support
From: Santosh Shilimkar @ 2014-09-25 17:48 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, sandeep_n-l0cyMroinI0,
joe-6d6DIl74uiNBDgjK7y7TUQ, Santosh Shilimkar
v4->v5
Sorry to spin v5 quickly but I missed few check-patch warnings which
were pointed by Joe Perches(thanks). I folded his changes [5] along with
few more check-patch warning fixes. I would like get this in for v3.18
merge window if David is happy with this version.
v3->v4
Couple of fixes in in error path as pointed [4] out by David. Rest of
the patches are unchanged from v3.
v2->v3
Update v3 after incorporating Jamal and David Miller's comment/suggestion
from earlier versions [1] [2]. After per the discussion here [3], the
controversial custom exports have been dropped now. And for future
future offload support additions, we will plug into generic frameworks
as an when they are available.
The network coprocessor (NetCP) is a hardware accelerator that processes
Ethernet packets. NetCP has a gigabit Ethernet (GbE) subsystem with a ethernet
switch sub-module to send and receive packets. NetCP also includes a packet
accelerator (PA) module to perform packet classification operations such as
header matching, and packet modification operations such as checksum
generation. NetCP can also optionally include a Security Accelerator(SA)
capable of performing IPSec operations on ingress/egress packets.
Keystone SoC's also have a 10 Gigabit Ethernet Subsystem (XGbE) which
includes a 3-port Ethernet switch sub-module capable of 10Gb/s and
1Gb/s rates per Ethernet port.
Both GBE and XGBE network processors supported using common driver. It
is also designed to handle future variants of NetCP.
Cc: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Sandeep Nair <sandeep_n-l0cyMroinI0@public.gmane.org>
Sandeep Nair (3):
Documentation: dt: net: Add binding doc for Keystone NetCP ethernet
driver
net: Add Keystone NetCP ethernet driver
MAINTAINER: net: Add TI NETCP Ethernet driver entry
.../devicetree/bindings/net/keystone-netcp.txt | 197 ++
MAINTAINERS | 7 +
drivers/net/ethernet/ti/Kconfig | 12 +-
drivers/net/ethernet/ti/Makefile | 4 +
drivers/net/ethernet/ti/netcp.h | 227 ++
drivers/net/ethernet/ti/netcp_core.c | 2262 ++++++++++++++++++++
drivers/net/ethernet/ti/netcp_ethss.c | 2173 +++++++++++++++++++
drivers/net/ethernet/ti/netcp_sgmii.c | 130 ++
drivers/net/ethernet/ti/netcp_xgbepcsr.c | 502 +++++
9 files changed, 5513 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/net/keystone-netcp.txt
create mode 100644 drivers/net/ethernet/ti/netcp.h
create mode 100644 drivers/net/ethernet/ti/netcp_core.c
create mode 100644 drivers/net/ethernet/ti/netcp_ethss.c
create mode 100644 drivers/net/ethernet/ti/netcp_sgmii.c
create mode 100644 drivers/net/ethernet/ti/netcp_xgbepcsr.c
Regards,
Santosh
[1] https://lkml.org/lkml/2014/4/22/805
[2] https://lkml.org/lkml/2014/8/15/218
[3] https://lkml.org/lkml/2014/9/11/691
[4] https://lkml.org/lkml/2014/9/15/403
[5] https://lkml.org/lkml/2014/9/25/332
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [Patch net-next] net_sched: remove the first parameter from tcf_exts_destroy()
From: Cong Wang @ 2014-09-25 17:26 UTC (permalink / raw)
To: netdev; +Cc: davem, Cong Wang, Jamal Hadi Salim
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
include/net/pkt_cls.h | 2 +-
net/sched/cls_api.c | 2 +-
net/sched/cls_basic.c | 4 ++--
net/sched/cls_bpf.c | 4 ++--
net/sched/cls_cgroup.c | 6 +++---
net/sched/cls_flow.c | 4 ++--
net/sched/cls_fw.c | 4 ++--
net/sched/cls_route.c | 4 ++--
net/sched/cls_rsvp.h | 4 ++--
net/sched/cls_tcindex.c | 4 ++--
net/sched/cls_u32.c | 4 ++--
11 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
index 6da46dc..73f9532 100644
--- a/include/net/pkt_cls.h
+++ b/include/net/pkt_cls.h
@@ -137,7 +137,7 @@ tcf_exts_exec(struct sk_buff *skb, struct tcf_exts *exts,
int tcf_exts_validate(struct net *net, struct tcf_proto *tp,
struct nlattr **tb, struct nlattr *rate_tlv,
struct tcf_exts *exts, bool ovr);
-void tcf_exts_destroy(struct tcf_proto *tp, struct tcf_exts *exts);
+void tcf_exts_destroy(struct tcf_exts *exts);
void tcf_exts_change(struct tcf_proto *tp, struct tcf_exts *dst,
struct tcf_exts *src);
int tcf_exts_dump(struct sk_buff *skb, struct tcf_exts *exts);
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index e547efd..77147c8 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -496,7 +496,7 @@ static int tc_dump_tfilter(struct sk_buff *skb, struct netlink_callback *cb)
return skb->len;
}
-void tcf_exts_destroy(struct tcf_proto *tp, struct tcf_exts *exts)
+void tcf_exts_destroy(struct tcf_exts *exts)
{
#ifdef CONFIG_NET_CLS_ACT
tcf_action_destroy(&exts->actions, TCA_ACT_UNBIND);
diff --git a/net/sched/cls_basic.c b/net/sched/cls_basic.c
index 1937298..fe20826 100644
--- a/net/sched/cls_basic.c
+++ b/net/sched/cls_basic.c
@@ -94,7 +94,7 @@ static void basic_delete_filter(struct rcu_head *head)
struct tcf_proto *tp = f->tp;
tcf_unbind_filter(tp, &f->res);
- tcf_exts_destroy(tp, &f->exts);
+ tcf_exts_destroy(&f->exts);
tcf_em_tree_destroy(tp, &f->ematches);
kfree(f);
}
@@ -161,7 +161,7 @@ static int basic_set_parms(struct net *net, struct tcf_proto *tp,
return 0;
errout:
- tcf_exts_destroy(tp, &e);
+ tcf_exts_destroy(&e);
return err;
}
diff --git a/net/sched/cls_bpf.c b/net/sched/cls_bpf.c
index 4e3f5bf..4318d06 100644
--- a/net/sched/cls_bpf.c
+++ b/net/sched/cls_bpf.c
@@ -93,7 +93,7 @@ static int cls_bpf_init(struct tcf_proto *tp)
static void cls_bpf_delete_prog(struct tcf_proto *tp, struct cls_bpf_prog *prog)
{
tcf_unbind_filter(tp, &prog->res);
- tcf_exts_destroy(tp, &prog->exts);
+ tcf_exts_destroy(&prog->exts);
bpf_prog_destroy(prog->filter);
@@ -217,7 +217,7 @@ static int cls_bpf_modify_existing(struct net *net, struct tcf_proto *tp,
errout_free:
kfree(bpf_ops);
errout:
- tcf_exts_destroy(tp, &exts);
+ tcf_exts_destroy(&exts);
return ret;
}
diff --git a/net/sched/cls_cgroup.c b/net/sched/cls_cgroup.c
index 15c34d4..3409f16 100644
--- a/net/sched/cls_cgroup.c
+++ b/net/sched/cls_cgroup.c
@@ -86,7 +86,7 @@ static void cls_cgroup_destroy_rcu(struct rcu_head *root)
struct cls_cgroup_head,
rcu);
- tcf_exts_destroy(head->tp, &head->exts);
+ tcf_exts_destroy(&head->exts);
tcf_em_tree_destroy(head->tp, &head->ematches);
kfree(head);
}
@@ -135,7 +135,7 @@ static int cls_cgroup_change(struct net *net, struct sk_buff *in_skb,
err = tcf_em_tree_validate(tp, tb[TCA_CGROUP_EMATCHES], &t);
if (err < 0) {
- tcf_exts_destroy(tp, &e);
+ tcf_exts_destroy(&e);
goto errout;
}
@@ -156,7 +156,7 @@ static void cls_cgroup_destroy(struct tcf_proto *tp)
struct cls_cgroup_head *head = rtnl_dereference(tp->root);
if (head) {
- tcf_exts_destroy(tp, &head->exts);
+ tcf_exts_destroy(&head->exts);
tcf_em_tree_destroy(tp, &head->ematches);
RCU_INIT_POINTER(tp->root, NULL);
kfree_rcu(head, rcu);
diff --git a/net/sched/cls_flow.c b/net/sched/cls_flow.c
index 95736fa..f18d27f7 100644
--- a/net/sched/cls_flow.c
+++ b/net/sched/cls_flow.c
@@ -354,7 +354,7 @@ static void flow_destroy_filter(struct rcu_head *head)
struct flow_filter *f = container_of(head, struct flow_filter, rcu);
del_timer_sync(&f->perturb_timer);
- tcf_exts_destroy(f->tp, &f->exts);
+ tcf_exts_destroy(&f->exts);
tcf_em_tree_destroy(f->tp, &f->ematches);
kfree(f);
}
@@ -533,7 +533,7 @@ static int flow_change(struct net *net, struct sk_buff *in_skb,
tcf_em_tree_destroy(tp, &t);
kfree(fnew);
err1:
- tcf_exts_destroy(tp, &e);
+ tcf_exts_destroy(&e);
return err;
}
diff --git a/net/sched/cls_fw.c b/net/sched/cls_fw.c
index 2650285..da805ae 100644
--- a/net/sched/cls_fw.c
+++ b/net/sched/cls_fw.c
@@ -126,7 +126,7 @@ static void fw_delete_filter(struct rcu_head *head)
struct tcf_proto *tp = f->tp;
tcf_unbind_filter(tp, &f->res);
- tcf_exts_destroy(tp, &f->exts);
+ tcf_exts_destroy(&f->exts);
kfree(f);
}
@@ -223,7 +223,7 @@ fw_change_attrs(struct net *net, struct tcf_proto *tp, struct fw_filter *f,
return 0;
errout:
- tcf_exts_destroy(tp, &e);
+ tcf_exts_destroy(&e);
return err;
}
diff --git a/net/sched/cls_route.c b/net/sched/cls_route.c
index ba96dea..b665aee 100644
--- a/net/sched/cls_route.c
+++ b/net/sched/cls_route.c
@@ -272,7 +272,7 @@ route4_delete_filter(struct rcu_head *head)
struct tcf_proto *tp = f->tp;
tcf_unbind_filter(tp, &f->res);
- tcf_exts_destroy(tp, &f->exts);
+ tcf_exts_destroy(&f->exts);
kfree(f);
}
@@ -456,7 +456,7 @@ static int route4_set_parms(struct net *net, struct tcf_proto *tp,
return 0;
errout:
- tcf_exts_destroy(tp, &e);
+ tcf_exts_destroy(&e);
return err;
}
diff --git a/net/sched/cls_rsvp.h b/net/sched/cls_rsvp.h
index b044c20..1c64a09 100644
--- a/net/sched/cls_rsvp.h
+++ b/net/sched/cls_rsvp.h
@@ -264,7 +264,7 @@ static void
rsvp_delete_filter(struct tcf_proto *tp, struct rsvp_filter *f)
{
tcf_unbind_filter(tp, &f->res);
- tcf_exts_destroy(tp, &f->exts);
+ tcf_exts_destroy(&f->exts);
kfree_rcu(f, rcu);
}
@@ -577,7 +577,7 @@ static int rsvp_change(struct net *net, struct sk_buff *in_skb,
errout:
kfree(f);
errout2:
- tcf_exts_destroy(tp, &e);
+ tcf_exts_destroy(&e);
return err;
}
diff --git a/net/sched/cls_tcindex.c b/net/sched/cls_tcindex.c
index 5054fae..e3c6fa3 100644
--- a/net/sched/cls_tcindex.c
+++ b/net/sched/cls_tcindex.c
@@ -169,7 +169,7 @@ tcindex_delete(struct tcf_proto *tp, unsigned long arg)
rcu_assign_pointer(*walk, rtnl_dereference(f->next));
}
tcf_unbind_filter(tp, &r->res);
- tcf_exts_destroy(tp, &r->exts);
+ tcf_exts_destroy(&r->exts);
if (f)
kfree_rcu(f, rcu);
return 0;
@@ -401,7 +401,7 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, unsigned long base,
kfree(cp->h);
errout:
kfree(cp);
- tcf_exts_destroy(tp, &e);
+ tcf_exts_destroy(&e);
return err;
}
diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c
index ef97a64..4be3ebf 100644
--- a/net/sched/cls_u32.c
+++ b/net/sched/cls_u32.c
@@ -359,7 +359,7 @@ static int u32_destroy_key(struct tcf_proto *tp,
bool free_pf)
{
tcf_unbind_filter(tp, &n->res);
- tcf_exts_destroy(tp, &n->exts);
+ tcf_exts_destroy(&n->exts);
if (n->ht_down)
n->ht_down->refcnt--;
#ifdef CONFIG_CLS_U32_PERF
@@ -606,7 +606,7 @@ static int u32_set_parms(struct net *net, struct tcf_proto *tp,
return 0;
errout:
- tcf_exts_destroy(tp, &e);
+ tcf_exts_destroy(&e);
return err;
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v4 2/3] net: Add Keystone NetCP ethernet driver
From: Santosh Shilimkar @ 2014-09-25 17:06 UTC (permalink / raw)
To: Joe Perches
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Nair, Sandeep
In-Reply-To: <1411655363.4026.13.camel@joe-AO725>
On Thursday 25 September 2014 10:29 AM, Joe Perches wrote:
> On Thu, 2014-09-25 at 10:03 -0400, Santosh Shilimkar wrote:
>> From: Sandeep Nair <sandeep_n-l0cyMroinI0@public.gmane.org>
>>
>> The network coprocessor (NetCP) is a hardware accelerator that processes
>> Ethernet packets. NetCP has a gigabit Ethernet (GbE) subsystem with a ethernet
>> switch sub-module to send and receive packets. NetCP also includes a packet
>> accelerator (PA) module to perform packet classification operations such as
>> header matching, and packet modification operations such as checksum
>> generation. NetCP can also optionally include a Security Accelerator(SA)
>> capable of performing IPSec operations on ingress/egress packets.
>
> Some checkpatch trivia you might consider:
Sure. I fold that in. Thanks !!
regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] mlx4: exploit skb->xmit_more to conditionally send doorbell
From: Eric Dumazet @ 2014-09-25 16:19 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: David Miller, netdev, Amir Vadai, John Fastabend
In-Reply-To: <1411659380.16953.29.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, 2014-09-25 at 08:36 -0700, Eric Dumazet wrote:
> 26.36% [kernel] [k] __copy_skb_header
Note to myself :
Time to optimize this thing, doing a memset() to copy a bunch of
consecutive fields.
^ permalink raw reply
* Re: [PATCH] neigh: check error pointer instead of NULL for ipv4_neigh_lookup()
From: Cong Wang @ 2014-09-25 16:18 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: netdev@vger.kernel.org, David S. Miller
In-Reply-To: <CAADnVQ+=yuG0+0kSj291MbbxMRvmeYN7D_2PkJsjkLWtnkt4WQ@mail.gmail.com>
On Thu, Sep 25, 2014 at 8:35 AM, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> assuming symptoms of this was a crash?
No.
> Or was it spotted just by code inspection?
Yes.
^ permalink raw reply
* Re: [PATCH net-next] mlx4: exploit skb->xmit_more to conditionally send doorbell
From: Alexei Starovoitov @ 2014-09-25 16:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Amir Vadai
In-Reply-To: <1411661114.16953.33.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, Sep 25, 2014 at 9:05 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2014-09-25 at 08:53 -0700, Alexei Starovoitov wrote:
>> On Thu, Sep 25, 2014 at 7:17 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > From: Eric Dumazet <edumazet@google.com>
>> >
>> > skb->xmit_more tells us if another skb is coming next.
>> >
>> > We need to send doorbell when : xmit_more is not set,
>> > or txqueue is stopped (preventing next skb to come immediately)
>> >
>> > Tested with a modified pktgen version, I got a 40% increase of
>> > throughput.
>>
>> this is awesome!
>>
>> I've been hacking pktgen as well based on Jesper's earlier patch,
>> but in slightly different way. Sounds like you already have working
>> pktgen with xmit_more. Do you mind sharing it? even rough patch
>> would be great.
>
> The plan was to add a 'pburst x' parameter.
>
> Because not only we want to avoid sending the doorbell, but we could
> also not doing the spinlock for every start_xmit().
exactly!
I also hacked
atomic_inc(&(pkt_dev->skb->users))
into
single atomic_add of N packets for bursting to amortize the cost
of both spin_lock and lock xadd
> We also can enforce a global [p]rate (say 100000 packets per second),
> but still allow pktgen to send burts of x packets to use (and test) this
> xmit_more
that would be nice. I'm not sure how yet.
> Nothing ready yet ;)
can't wait :)
^ permalink raw reply
* Re: [PATCH net-next] mlx4: exploit skb->xmit_more to conditionally send doorbell
From: Eric Dumazet @ 2014-09-25 16:05 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: David Miller, netdev, Amir Vadai
In-Reply-To: <CAADnVQJ_FfZEUbFBz4wwZM9Gfbsagfjk51VVbjWJPG7KgJjHWQ@mail.gmail.com>
On Thu, 2014-09-25 at 08:53 -0700, Alexei Starovoitov wrote:
> On Thu, Sep 25, 2014 at 7:17 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > From: Eric Dumazet <edumazet@google.com>
> >
> > skb->xmit_more tells us if another skb is coming next.
> >
> > We need to send doorbell when : xmit_more is not set,
> > or txqueue is stopped (preventing next skb to come immediately)
> >
> > Tested with a modified pktgen version, I got a 40% increase of
> > throughput.
>
> this is awesome!
>
> I've been hacking pktgen as well based on Jesper's earlier patch,
> but in slightly different way. Sounds like you already have working
> pktgen with xmit_more. Do you mind sharing it? even rough patch
> would be great.
The plan was to add a 'pburst x' parameter.
Because not only we want to avoid sending the doorbell, but we could
also not doing the spinlock for every start_xmit().
We also can enforce a global [p]rate (say 100000 packets per second),
but still allow pktgen to send burts of x packets to use (and test) this
xmit_more
Nothing ready yet ;)
^ permalink raw reply
* Re: [PATCH net-next 2/3] ipv6: mld: do not overwrite uri when receiving an mldv2 query
From: David L Stevens @ 2014-09-25 16:02 UTC (permalink / raw)
To: Daniel Borkmann, davem; +Cc: hannes, netdev
In-Reply-To: <1411455828-5196-3-git-send-email-dborkman@redhat.com>
While I can see the case you're making, I think the intent of MRC is
violated by arbitrary URI.
> 5.1.3. Maximum Response Code
>
> The Maximum Response Code field specifies the maximum time allowed
> before sending a responding Report.
>...
> Small values of Maximum Response Delay allow MLDv2 routers to tune
> the "leave latency" (the time between the moment the last node on a
> link ceases to listen to a specific multicast address and the moment
> the routing protocol is notified that there are no more listeners for
> that address). Larger values, especially in the exponential range,
> allow the tuning of the burstiness of MLD traffic on a link.
If URI is larger than MRD, then a lost unsolicited report, or series,
specifically will *not* propagate changes throughout the network in less
than MRD*QRV, as intended.
It was an intentional design choice, not required or prohibited by RFC.
I'm not sure what problem you think it's causing, but if they are not
equal, I think at least the URI should be enforced to <= MRD. The querier,
IMO, should set these network-wide relevant parameters, not the individual
hosts.
Is there actually some bad effect from this?
+-DLS
^ permalink raw reply
* RE: netxen: BUG: sleeping function called from invalid context at include/linux/netdevice.h:476
From: Manish Chopra @ 2014-09-25 16:01 UTC (permalink / raw)
To: Mike Galbraith, linux-kernel; +Cc: Sony Chacko, Rajesh Borundia, netdev
In-Reply-To: <1411654896.15810.52.camel@marge.simpson.net>
> -----Original Message-----
> From: Mike Galbraith [mailto:umgwanakikbuti@gmail.com]
> Sent: Thursday, September 25, 2014 7:52 PM
> To: linux-kernel
> Cc: Manish Chopra; Sony Chacko; Rajesh Borundia; netdev
> Subject: netxen: BUG: sleeping function called from invalid context at
> include/linux/netdevice.h:476
>
> Greetings,
>
> While testing some sched patches that require CONFIG_DEBUG_ATOMIC_SLEEP,
> the below fell out.
>
> /etc/init.d/network restart -> gripe
>
> [ 97.850408] BUG: sleeping function called from invalid context at
> include/linux/netdevice.h:476
> [ 97.941177] in_atomic(): 1, irqs_disabled(): 0, pid: 6458, name: ip
> [ 98.012784] Preemption disabled at:[<ffffffffa0509719>]
> __netxen_nic_down+0x79/0x1b0 [netxen_nic]
> [ 98.047283]
> [ 98.047289] CPU: 63 PID: 6458 Comm: ip Tainted: G E 3.17.0-default #7
> [ 98.047291] Hardware name: Hewlett-Packard ProLiant DL980 G7, BIOS P66
> 07/07/2010
> [ 98.047295] 00000000ffffffff ffff88003702f528 ffffffff81589dbd
> 0000000000000000
> [ 98.047301] ffff88026ee96210 ffff88003702f548 ffffffff8108e1df
> ffff88026ee96210
> [ 98.047305] 0000000000000000 ffff88003702f578 ffffffff8108e298
> ffff88026bf89c38
> [ 98.047307] Call Trace:
> [ 98.047313] [<ffffffff81589dbd>] dump_stack+0x4d/0x90
> [ 98.047331] [<ffffffff8108e1df>] ___might_sleep+0x10f/0x180
> [ 98.047343] [<ffffffff8108e298>] __might_sleep+0x48/0xd0
> [ 98.047348] [<ffffffffa0506d54>] netxen_napi_disable+0x84/0xe0
> [netxen_nic]
> [ 98.047353] [<ffffffffa05097f0>] __netxen_nic_down+0x150/0x1b0
> [netxen_nic]
> [ 98.047367] [<ffffffffa0509b0b>] netxen_nic_close+0x1b/0x20 [netxen_nic]
> [ 98.047375] [<ffffffff814aa525>] __dev_close_many+0x95/0xe0
> [ 98.047379] [<ffffffff814aa5a6>] __dev_close+0x36/0x50
> [ 98.047384] [<ffffffff814ab89c>] __dev_change_flags+0xac/0x180
> [ 98.047389] [<ffffffff814ab9a7>] dev_change_flags+0x37/0x80
> [ 98.047398] [<ffffffff814be874>] do_setlink+0x244/0x7e0
> [ 98.047403] [<ffffffff814c0310>] rtnl_newlink+0x5a0/0x7d0
> [ 98.047408] [<ffffffff814bfeba>] ? rtnl_newlink+0x14a/0x7d0
> [ 98.047421] [<ffffffff8105259c>] ? __do_page_fault+0x2ac/0x520
> [ 98.047431] [<ffffffff812a14a0>] ? apparmor_capable+0x20/0x60
> [ 98.047436] [<ffffffff814bf981>] rtnetlink_rcv_msg+0xa1/0x240
> [ 98.047446] [<ffffffff81308f86>] ? rhashtable_lookup_compare+0x46/0x70
> [ 98.047451] [<ffffffff814bf8e0>] ? __rtnl_unlock+0x20/0x20
> [ 98.047463] [<ffffffff814dc3d9>] netlink_rcv_skb+0x89/0xb0
> [ 98.047466] [<ffffffff814bfb7c>] rtnetlink_rcv+0x2c/0x40
> [ 98.047468] [<ffffffff814dbdc9>] netlink_unicast+0x119/0x180
> [ 98.047473] [<ffffffff81306a3c>] ? memcpy_fromiovec+0x6c/0x90
> [ 98.047477] [<ffffffff814dc7c0>] netlink_sendmsg+0x3c0/0x450
> [ 98.047487] [<ffffffff8149449c>] sock_sendmsg+0x9c/0xd0
> [ 98.047497] [<ffffffff810aa113>] ? __wake_up+0x53/0x70
> [ 98.047502] [<ffffffff8108e298>] ? __might_sleep+0x48/0xd0
> [ 98.047509] [<ffffffff814a204e>] ? verify_iovec+0x5e/0xf0
> [ 98.047512] [<ffffffff81494df6>] ___sys_sendmsg+0x436/0x440
> [ 98.047515] [<ffffffff8108e298>] ? __might_sleep+0x48/0xd0
> [ 98.047523] [<ffffffff81194513>] ? might_fault+0x43/0x50
> [ 98.047525] [<ffffffff81491eef>] ? copy_to_user+0x2f/0x40
> [ 98.047528] [<ffffffff814951cc>] ? ___sys_recvmsg+0x19c/0x310
> [ 98.047531] [<ffffffff8105259c>] ? __do_page_fault+0x2ac/0x520
> [ 98.047538] [<ffffffff8119e681>] ? __vma_link_rb+0x101/0x120
> [ 98.047544] [<ffffffff8119fef8>] ? do_brk+0x1c8/0x340
> [ 98.047550] [<ffffffff814924a2>] ? SyS_getsockname+0xb2/0xc0
> [ 98.047555] [<ffffffff81494fd9>] __sys_sendmsg+0x49/0x80
> [ 98.047558] [<ffffffff81495029>] SyS_sendmsg+0x19/0x20
> [ 98.047567] [<ffffffff8158f7a9>] system_call_fastpath+0x16/0x1b
>
> (gdb) list *__netxen_nic_down+0x79
> 0x8749 is in __netxen_nic_down
> (drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c:1190).
> 1185 if (!test_and_clear_bit(__NX_DEV_UP, &adapter->state))
> 1186 return;
> 1187
> 1188 smp_mb();
> 1189 spin_lock(&adapter->tx_clean_lock);
> 1190 netif_carrier_off(netdev);
> 1191 netif_tx_disable(netdev);
> 1192
> 1193 if (adapter->capabilities &
> NX_FW_CAPABILITY_LINK_NOTIFICATION)
> 1194 netxen_linkevent_request(adapter, 0);
Hello Mike,
Thanks for finding this out. Mostly I have fix for it.
I will send a patch to net for fixing it after doing some testing.
Thanks,
Manish
^ permalink raw reply
* Re: [net-next PATCH 1/1 V4] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE
From: Tom Herbert @ 2014-09-25 15:58 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Jamal Hadi Salim, Eric Dumazet, Linux Netdev List,
David S. Miller, Alexander Duyck,
Toke Høiland-Jørgensen, Florian Westphal, Dave Taht,
John Fastabend, Daniel Borkmann, Hannes Frederic Sowa
In-Reply-To: <20140925172329.7460f787@redhat.com>
On Thu, Sep 25, 2014 at 8:23 AM, Jesper Dangaard Brouer
<brouer@redhat.com> wrote:
> On Thu, 25 Sep 2014 08:05:38 -0700
> Tom Herbert <therbert@google.com> wrote:
>
>> On Thu, Sep 25, 2014 at 7:57 AM, Jesper Dangaard Brouer
>> <brouer@redhat.com> wrote:
>> > On Thu, 25 Sep 2014 07:40:33 -0700
>> > Tom Herbert <therbert@google.com> wrote:
>> >
>> >> A few test results in patch 0 are good. I like to have results for
>> >> with and without patch. These should two things: 1) Any regressions
>> >> caused by the patch 2) Performance gains (in that order of importance
>> >> :-) ). There doesn't need to be a lot here, just something reasonably
>> >> representative, simple, and should be easily reproducible. My
>> >> expectation in bulk dequeue is that we should see no obvious
>> >> regression and hopefully an improvement in CPU utilization-- are you
>> >> able to verify this?
>> >
>> > We are saving 3% CPU, as I described in my post with subject:
>> > "qdisc/UDP_STREAM: measuring effect of qdisc bulk dequeue":
>> > http://thread.gmane.org/gmane.linux.network/331152/focus=331154
>> >
>> > Using UDP_STREAM on 1Gbit/s driver igb, I can show that the
>> > _raw_spin_lock calls are reduced with approx 3%, when enabling
>> > bulking of just 2 packets.
>> >
>>
>> That's great. In commit log, would be good to have results with
>> TCP_STREAM also and please report aggregate CPU utilization changes
>> (like from mpstat).
>
> The TCP_STREAM is not a good test for this, because unless disabling
> both TSO and GSO the packets will not hit the code path (that this
> patch changes). When we later add support for TSO and GSO bulking,
> then it will make sense to include TCP_STREAM testing, not before.
>
Disabling TSO and GSO is fine. I'm interested to see interactions with TCP.
> I will redo the tests, once I get home to my testlab, as the remote lab
> I'm using now is annoyingly slow rebooting machines, as we not longer
> have a runtime option for enable/disable (I'm currently in Switzerland).
>
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Sr. Network Kernel Developer at Red Hat
> Author of http://www.iptv-analyzer.org
> LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next] mlx4: exploit skb->xmit_more to conditionally send doorbell
From: Alexei Starovoitov @ 2014-09-25 15:53 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Amir Vadai
In-Reply-To: <1411654669.16953.17.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, Sep 25, 2014 at 7:17 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> skb->xmit_more tells us if another skb is coming next.
>
> We need to send doorbell when : xmit_more is not set,
> or txqueue is stopped (preventing next skb to come immediately)
>
> Tested with a modified pktgen version, I got a 40% increase of
> throughput.
this is awesome!
I've been hacking pktgen as well based on Jesper's earlier patch,
but in slightly different way. Sounds like you already have working
pktgen with xmit_more. Do you mind sharing it? even rough patch
would be great.
Thanks
^ permalink raw reply
* Re: [PATCH v2 net-next 3/3] tcp: better TCP_SKB_CB layout to reduce cache line misses
From: Christoph Paasch @ 2014-09-25 15:48 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, netdev, Yuchung Cheng, Neal Cardwell
In-Reply-To: <1411468452-3729-4-git-send-email-edumazet@google.com>
On 23/09/14 - 03:34:12, Eric Dumazet wrote:
> TCP maintains lists of skb in write queue, and in receive queues
> (in order and out of order queues)
>
> Scanning these lists both in input and output path usually requires
> access to skb->next, TCP_SKB_CB(skb)->seq, and TCP_SKB_CB(skb)->end_seq
>
> These fields are currently in two different cache lines, meaning we
> waste lot of memory bandwidth when these queues are big and flows
> have either packet drops or packet reorders.
>
> We can move TCP_SKB_CB(skb)->header at the end of TCP_SKB_CB, because
> this header is not used in fast path. This allows TCP to search much faster
> in the skb lists.
>
> Even with regular flows, we save one cache line miss in fast path.
>
> Thanks to Christoph Paasch for noticing we need to cleanup
> skb->cb[] (IPCB/IP6CB) before entering IP stack in tx path.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> include/net/tcp.h | 12 ++++++------
> net/ipv4/tcp_ipv4.c | 7 +++++++
> net/ipv4/tcp_output.c | 5 +++++
> net/ipv6/tcp_ipv6.c | 7 +++++++
> 4 files changed, 25 insertions(+), 6 deletions(-)
Hello Eric,
I think that in tcp_v4_hnd_req() and tcp_v4_save_options() we also need to
avoid calling IPCB() and do TCP_SKB_CB(skb)->header.h4.opt instead.
Cheers,
Christoph
^ permalink raw reply
* Re: [PATCH net-next] mlx4: exploit skb->xmit_more to conditionally send doorbell
From: Eric Dumazet @ 2014-09-25 15:40 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: David Miller, netdev, Amir Vadai, John Fastabend
In-Reply-To: <1411659380.16953.29.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, 2014-09-25 at 08:36 -0700, Eric Dumazet wrote:
> So playing with TSO=off (but GSO=on), we see about 12 % increase of
> throughput on a TCP_STREAM flow.
Correction, this was a 20 % increase.
( 849284 pps -> 1023469 pps)
^ permalink raw reply
* Re: [PATCH net-next] mlx4: exploit skb->xmit_more to conditionally send doorbell
From: Eric Dumazet @ 2014-09-25 15:36 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: David Miller, netdev, Amir Vadai, John Fastabend
In-Reply-To: <1411657615.16953.21.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, 2014-09-25 at 08:06 -0700, Eric Dumazet wrote:
>
> But... Nothing yet in qdisc layer sets xmit_more, unless TSO is
> disabled, and a GSO packet is segmented.
>
> So you might notice some improvement with this patch, but not if you use
> TSO, and a 40GB NIC is better with TSO on you know ;)
>
So playing with TSO=off (but GSO=on), we see about 12 % increase of
throughput on a TCP_STREAM flow.
And kernel profile clearly shows the difference of sending or not the
doorbell, as mlx4_en_xmit() shifts. Note also mlx4_en_free_tx_desc()
disappears, this might point to some false sharing or something worth
investigating.
Before patch :
26.36% [kernel] [k] __copy_skb_header
16.59% [kernel] [k] mlx4_en_xmit
5.62% [kernel] [k] __alloc_skb
5.48% [kernel] [k] copy_user_enhanced_fast_string
4.48% [kernel] [k] skb_segment
2.46% [kernel] [k] mlx4_en_free_tx_desc.isra.27
2.31% [kernel] [k] _raw_spin_lock
2.10% [kernel] [k] memcpy
2.01% [kernel] [k] tcp_sendmsg
1.62% [kernel] [k] __iowrite64_copy
After patch :
32.78% [kernel] [k] __copy_skb_header
8.26% [kernel] [k] mlx4_en_xmit
7.25% [kernel] [k] __alloc_skb
7.18% [kernel] [k] copy_user_enhanced_fast_string
4.39% [kernel] [k] skb_segment
2.87% [kernel] [k] memcpy
2.59% [kernel] [k] tcp_sendmsg
2.50% [kernel] [k] _raw_spin_lock
2.38% [kernel] [k] dev_hard_start_xmit
1.52% [kernel] [k] tcp_gso_segment
1.50% [kernel] [k] kmem_cache_alloc_node_trace
1.40% [kernel] [k] kmem_cache_alloc_node
1.16% [kernel] [k] ip_send_check
^ permalink raw reply
* Re: [PATCH] neigh: check error pointer instead of NULL for ipv4_neigh_lookup()
From: Alexei Starovoitov @ 2014-09-25 15:35 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev@vger.kernel.org, David S. Miller
In-Reply-To: <1411603673-19084-1-git-send-email-xiyou.wangcong@gmail.com>
On Wed, Sep 24, 2014 at 5:07 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> Fixes: commit f187bc6efb7250afee0e2009b6106 ("ipv4: No need to set generic neighbour pointer")
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
> net/ipv4/route.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 173e7ea..cbadb94 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -746,7 +746,7 @@ static void __ip_do_redirect(struct rtable *rt, struct sk_buff *skb, struct flow
> }
>
> n = ipv4_neigh_lookup(&rt->dst, NULL, &new_gw);
> - if (n) {
> + if (!IS_ERR(n)) {
> if (!(n->nud_state & NUD_VALID)) {
> neigh_event_send(n, NULL);
assuming symptoms of this was a crash?
Could you share the stack trace to see how we got to this state ?
Or was it spotted just by code inspection?
Thanks!
^ permalink raw reply
* Re: [net-next PATCH 1/1 V4] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE
From: Jesper Dangaard Brouer @ 2014-09-25 15:23 UTC (permalink / raw)
To: Tom Herbert
Cc: Jamal Hadi Salim, Eric Dumazet, Linux Netdev List,
David S. Miller, Alexander Duyck,
Toke Høiland-Jørgensen, Florian Westphal, Dave Taht,
John Fastabend, Daniel Borkmann, Hannes Frederic Sowa, brouer
In-Reply-To: <CA+mtBx9ZW0qYh+_BEEVTgZ79Xbq0bH1Agfss_7kdEus_syeMhA@mail.gmail.com>
On Thu, 25 Sep 2014 08:05:38 -0700
Tom Herbert <therbert@google.com> wrote:
> On Thu, Sep 25, 2014 at 7:57 AM, Jesper Dangaard Brouer
> <brouer@redhat.com> wrote:
> > On Thu, 25 Sep 2014 07:40:33 -0700
> > Tom Herbert <therbert@google.com> wrote:
> >
> >> A few test results in patch 0 are good. I like to have results for
> >> with and without patch. These should two things: 1) Any regressions
> >> caused by the patch 2) Performance gains (in that order of importance
> >> :-) ). There doesn't need to be a lot here, just something reasonably
> >> representative, simple, and should be easily reproducible. My
> >> expectation in bulk dequeue is that we should see no obvious
> >> regression and hopefully an improvement in CPU utilization-- are you
> >> able to verify this?
> >
> > We are saving 3% CPU, as I described in my post with subject:
> > "qdisc/UDP_STREAM: measuring effect of qdisc bulk dequeue":
> > http://thread.gmane.org/gmane.linux.network/331152/focus=331154
> >
> > Using UDP_STREAM on 1Gbit/s driver igb, I can show that the
> > _raw_spin_lock calls are reduced with approx 3%, when enabling
> > bulking of just 2 packets.
> >
>
> That's great. In commit log, would be good to have results with
> TCP_STREAM also and please report aggregate CPU utilization changes
> (like from mpstat).
The TCP_STREAM is not a good test for this, because unless disabling
both TSO and GSO the packets will not hit the code path (that this
patch changes). When we later add support for TSO and GSO bulking,
then it will make sense to include TCP_STREAM testing, not before.
I will redo the tests, once I get home to my testlab, as the remote lab
I'm using now is annoyingly slow rebooting machines, as we not longer
have a runtime option for enable/disable (I'm currently in Switzerland).
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [net-next PATCH 1/1 V4] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE
From: Eric Dumazet @ 2014-09-25 15:12 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Tom Herbert, Jamal Hadi Salim, Linux Netdev List, David S. Miller,
Alexander Duyck, Toke Høiland-Jørgensen,
Florian Westphal, Dave Taht, John Fastabend, Daniel Borkmann,
Hannes Frederic Sowa
In-Reply-To: <20140925165738.646d0783@redhat.com>
On Thu, 2014-09-25 at 16:57 +0200, Jesper Dangaard Brouer wrote:
> We are saving 3% CPU, as I described in my post with subject:
> "qdisc/UDP_STREAM: measuring effect of qdisc bulk dequeue":
> http://thread.gmane.org/gmane.linux.network/331152/focus=331154
>
> Using UDP_STREAM on 1Gbit/s driver igb, I can show that the
> _raw_spin_lock calls are reduced with approx 3%, when enabling
> bulking of just 2 packets.
>
> This test can only demonstrates a CPU usage reduction, as the
> throughput is already at maximum link (bandwidth) capacity.
>
> Notice netperf option "-m 1472" which makes sure we are not sending
> UDP IP-fragments::
>
> netperf -H 192.168.111.2 -t UDP_STREAM -l 120 -- -m 1472
>
> Results from perf diff::
>
> # Command: perf diff
> # Event 'cycles'
> # Baseline Delta Symbol
> # no-bulk bulk(1)
> # ........ ....... .........................................
> #
> 7.05% -3.03% [k] _raw_spin_lock
> 6.34% +0.23% [k] copy_user_enhanced_fast_string
> 6.30% +0.26% [k] fib_table_lookup
> 3.03% +0.01% [k] __slab_free
> 3.00% +0.08% [k] intel_idle
> 2.49% +0.05% [k] sock_alloc_send_pskb
> 2.31% +0.30% netperf [.] send_omni_inner
> 2.12% +0.12% netperf [.] send_data
> 2.11% +0.10% [k] udp_sendmsg
> 1.96% +0.02% [k] __ip_append_data
> 1.48% -0.01% [k] __alloc_skb
> 1.46% +0.07% [k] __mkroute_output
> 1.34% +0.05% [k] __ip_select_ident
> 1.29% +0.03% [k] check_leaf
> 1.27% +0.09% [k] __skb_get_hash
>
> A nitpick is that, this testing were done on V2 of the patchset.
>
You could avoid the fib_table_lookup() cost by using netperf -- -N -n
(connected UDP sockets)
And of course reduce message sizes to increase pps
^ permalink raw reply
* Re: [PATCH net-next] mlx4: exploit skb->xmit_more to conditionally send doorbell
From: Eric Dumazet @ 2014-09-25 15:06 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: David Miller, netdev, Amir Vadai, John Fastabend
In-Reply-To: <20140925164333.7cba128a@redhat.com>
On Thu, 2014-09-25 at 16:43 +0200, Jesper Dangaard Brouer wrote:
> On Thu, 25 Sep 2014 07:17:49 -0700
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > From: Eric Dumazet <edumazet@google.com>
> >
> > Tested with a modified pktgen version, I got a 40% increase of
> > throughput.
>
> Pktgen is artificial benchmarking, you know ;-) :-P
>
> If you really must use pktgen for this, you can use an unmodified
> pktgen against the qdisc layer by adding a VLAN interface on-top of the
> device you want to test. I blame John, for telling me this ;-)
>
> /me running away
But... Nothing yet in qdisc layer sets xmit_more, unless TSO is
disabled, and a GSO packet is segmented.
So you might notice some improvement with this patch, but not if you use
TSO, and a 40GB NIC is better with TSO on you know ;)
^ permalink raw reply
* Re: [net-next PATCH 1/1 V4] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE
From: Tom Herbert @ 2014-09-25 15:05 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Jamal Hadi Salim, Eric Dumazet, Linux Netdev List,
David S. Miller, Alexander Duyck,
Toke Høiland-Jørgensen, Florian Westphal, Dave Taht,
John Fastabend, Daniel Borkmann, Hannes Frederic Sowa
In-Reply-To: <20140925165738.646d0783@redhat.com>
On Thu, Sep 25, 2014 at 7:57 AM, Jesper Dangaard Brouer
<brouer@redhat.com> wrote:
> On Thu, 25 Sep 2014 07:40:33 -0700
> Tom Herbert <therbert@google.com> wrote:
>
>> A few test results in patch 0 are good. I like to have results for
>> with and without patch. These should two things: 1) Any regressions
>> caused by the patch 2) Performance gains (in that order of importance
>> :-) ). There doesn't need to be a lot here, just something reasonably
>> representative, simple, and should be easily reproducible. My
>> expectation in bulk dequeue is that we should see no obvious
>> regression and hopefully an improvement in CPU utilization-- are you
>> able to verify this?
>
> We are saving 3% CPU, as I described in my post with subject:
> "qdisc/UDP_STREAM: measuring effect of qdisc bulk dequeue":
> http://thread.gmane.org/gmane.linux.network/331152/focus=331154
>
> Using UDP_STREAM on 1Gbit/s driver igb, I can show that the
> _raw_spin_lock calls are reduced with approx 3%, when enabling
> bulking of just 2 packets.
>
That's great. In commit log, would be good to have results with
TCP_STREAM also and please report aggregate CPU utilization changes
(like from mpstat).
Thanks,
Tom
> This test can only demonstrates a CPU usage reduction, as the
> throughput is already at maximum link (bandwidth) capacity.
>
> Notice netperf option "-m 1472" which makes sure we are not sending
> UDP IP-fragments::
>
> netperf -H 192.168.111.2 -t UDP_STREAM -l 120 -- -m 1472
>
> Results from perf diff::
>
> # Command: perf diff
> # Event 'cycles'
> # Baseline Delta Symbol
> # no-bulk bulk(1)
> # ........ ....... .........................................
> #
> 7.05% -3.03% [k] _raw_spin_lock
> 6.34% +0.23% [k] copy_user_enhanced_fast_string
> 6.30% +0.26% [k] fib_table_lookup
> 3.03% +0.01% [k] __slab_free
> 3.00% +0.08% [k] intel_idle
> 2.49% +0.05% [k] sock_alloc_send_pskb
> 2.31% +0.30% netperf [.] send_omni_inner
> 2.12% +0.12% netperf [.] send_data
> 2.11% +0.10% [k] udp_sendmsg
> 1.96% +0.02% [k] __ip_append_data
> 1.48% -0.01% [k] __alloc_skb
> 1.46% +0.07% [k] __mkroute_output
> 1.34% +0.05% [k] __ip_select_ident
> 1.29% +0.03% [k] check_leaf
> 1.27% +0.09% [k] __skb_get_hash
>
> A nitpick is that, this testing were done on V2 of the patchset.
>
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Sr. Network Kernel Developer at Red Hat
> Author of http://www.iptv-analyzer.org
> LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [net-next PATCH 1/1 V4] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE
From: Jesper Dangaard Brouer @ 2014-09-25 14:57 UTC (permalink / raw)
To: Tom Herbert
Cc: Jamal Hadi Salim, Eric Dumazet, Linux Netdev List,
David S. Miller, Alexander Duyck,
Toke Høiland-Jørgensen, Florian Westphal, Dave Taht,
John Fastabend, Daniel Borkmann, Hannes Frederic Sowa, brouer
In-Reply-To: <CA+mtBx8Nie9AiCG6iuY+EN7HiLAe-bxWpZxTpRhASmYabRUyFA@mail.gmail.com>
On Thu, 25 Sep 2014 07:40:33 -0700
Tom Herbert <therbert@google.com> wrote:
> A few test results in patch 0 are good. I like to have results for
> with and without patch. These should two things: 1) Any regressions
> caused by the patch 2) Performance gains (in that order of importance
> :-) ). There doesn't need to be a lot here, just something reasonably
> representative, simple, and should be easily reproducible. My
> expectation in bulk dequeue is that we should see no obvious
> regression and hopefully an improvement in CPU utilization-- are you
> able to verify this?
We are saving 3% CPU, as I described in my post with subject:
"qdisc/UDP_STREAM: measuring effect of qdisc bulk dequeue":
http://thread.gmane.org/gmane.linux.network/331152/focus=331154
Using UDP_STREAM on 1Gbit/s driver igb, I can show that the
_raw_spin_lock calls are reduced with approx 3%, when enabling
bulking of just 2 packets.
This test can only demonstrates a CPU usage reduction, as the
throughput is already at maximum link (bandwidth) capacity.
Notice netperf option "-m 1472" which makes sure we are not sending
UDP IP-fragments::
netperf -H 192.168.111.2 -t UDP_STREAM -l 120 -- -m 1472
Results from perf diff::
# Command: perf diff
# Event 'cycles'
# Baseline Delta Symbol
# no-bulk bulk(1)
# ........ ....... .........................................
#
7.05% -3.03% [k] _raw_spin_lock
6.34% +0.23% [k] copy_user_enhanced_fast_string
6.30% +0.26% [k] fib_table_lookup
3.03% +0.01% [k] __slab_free
3.00% +0.08% [k] intel_idle
2.49% +0.05% [k] sock_alloc_send_pskb
2.31% +0.30% netperf [.] send_omni_inner
2.12% +0.12% netperf [.] send_data
2.11% +0.10% [k] udp_sendmsg
1.96% +0.02% [k] __ip_append_data
1.48% -0.01% [k] __alloc_skb
1.46% +0.07% [k] __mkroute_output
1.34% +0.05% [k] __ip_select_ident
1.29% +0.03% [k] check_leaf
1.27% +0.09% [k] __skb_get_hash
A nitpick is that, this testing were done on V2 of the patchset.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH v1 4/4] ARM: Documentation: Update fec dts binding doc
From: Richard Cochran @ 2014-09-25 14:43 UTC (permalink / raw)
To: Luwei Zhou
Cc: davem, netdev, shawn.guo, bhutchings, R49496, b38611, b20596,
stephen
In-Reply-To: <1411632621-17429-5-git-send-email-b45643@freescale.com>
On Thu, Sep 25, 2014 at 04:10:21PM +0800, Luwei Zhou wrote:
> This patch update fec devicetree binding doc that add Optional properties
> "pps-channel".
Again, use the PTP pin interface. We don't need a random new FEC DT
property for this.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH net-next] mlx4: exploit skb->xmit_more to conditionally send doorbell
From: Jesper Dangaard Brouer @ 2014-09-25 14:43 UTC (permalink / raw)
To: Eric Dumazet; +Cc: brouer, David Miller, netdev, Amir Vadai, John Fastabend
In-Reply-To: <1411654669.16953.17.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, 25 Sep 2014 07:17:49 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Tested with a modified pktgen version, I got a 40% increase of
> throughput.
Pktgen is artificial benchmarking, you know ;-) :-P
If you really must use pktgen for this, you can use an unmodified
pktgen against the qdisc layer by adding a VLAN interface on-top of the
device you want to test. I blame John, for telling me this ;-)
/me running away
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH v1 3/4] net: fec: ptp: Enalbe PPS ouput based on ptp clock
From: Richard Cochran @ 2014-09-25 14:41 UTC (permalink / raw)
To: Luwei Zhou
Cc: davem, netdev, shawn.guo, bhutchings, R49496, b38611, b20596,
stephen
In-Reply-To: <1411632621-17429-4-git-send-email-b45643@freescale.com>
On Thu, Sep 25, 2014 at 04:10:20PM +0800, Luwei Zhou wrote:
> FEC ptp timer has 4 channel compare/trigger function. It can be used to enable pps output.
> The pulse would be ouput high exactly on N second. The pulse ouput high on compare event mode
> is used to produce pulse per second. The pulse width would be one cycle based on ptp timer clock
> source.Since 31-bit ptp hardware timer is used, the timer will wrap more than 2 seconds. We need to
> reload the compare compare event about every 1 second.
>
> Signed-off-by: Luwei Zhou <b45643@freescale.com>
> ---
> drivers/net/ethernet/freescale/fec.h | 7 +
> drivers/net/ethernet/freescale/fec_main.c | 2 +
> drivers/net/ethernet/freescale/fec_ptp.c | 223 +++++++++++++++++++++++++++++-
> 3 files changed, 231 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
> index 26fb1de..f8e23e6 100644
> --- a/drivers/net/ethernet/freescale/fec.h
> +++ b/drivers/net/ethernet/freescale/fec.h
> @@ -481,12 +481,19 @@ struct fec_enet_private {
> unsigned int tx_pkts_itr;
> unsigned int tx_time_itr;
> unsigned int itr_clk_rate;
> +
> + /* pps */
> + int pps_channel;
> + unsigned int reload_period;
> + int pps_enable;
> + unsigned int next_counter;
> };
>
> void fec_ptp_init(struct platform_device *pdev);
> void fec_ptp_start_cyclecounter(struct net_device *ndev);
> int fec_ptp_set(struct net_device *ndev, struct ifreq *ifr);
> int fec_ptp_get(struct net_device *ndev, struct ifreq *ifr);
> +uint fec_ptp_check_pps_event(struct fec_enet_private *fep);
>
> /****************************************************************************/
> #endif /* FEC_H */
> diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
> index 3a4ec0f..5a4ce36 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -1558,6 +1558,8 @@ fec_enet_interrupt(int irq, void *dev_id)
> complete(&fep->mdio_done);
> }
>
> + fec_ptp_check_pps_event(fep);
> +
> return ret;
> }
>
> diff --git a/drivers/net/ethernet/freescale/fec_ptp.c b/drivers/net/ethernet/freescale/fec_ptp.c
> index e2bf786..c55239d 100644
> --- a/drivers/net/ethernet/freescale/fec_ptp.c
> +++ b/drivers/net/ethernet/freescale/fec_ptp.c
> @@ -61,6 +61,24 @@
> #define FEC_T_INC_CORR_MASK 0x00007f00
> #define FEC_T_INC_CORR_OFFSET 8
>
> +#define FEC_T_CTRL_PINPER 0x00000080
> +#define FEC_T_TF0_MASK 0x00000001
> +#define FEC_T_TF0_OFFSET 0
> +#define FEC_T_TF1_MASK 0x00000002
> +#define FEC_T_TF1_OFFSET 1
> +#define FEC_T_TF2_MASK 0x00000004
> +#define FEC_T_TF2_OFFSET 2
> +#define FEC_T_TF3_MASK 0x00000008
> +#define FEC_T_TF3_OFFSET 3
> +#define FEC_T_TDRE_MASK 0x00000001
> +#define FEC_T_TDRE_OFFSET 0
> +#define FEC_T_TMODE_MASK 0x0000003C
> +#define FEC_T_TMODE_OFFSET 2
> +#define FEC_T_TIE_MASK 0x00000040
> +#define FEC_T_TIE_OFFSET 6
> +#define FEC_T_TF_MASK 0x00000080
> +#define FEC_T_TF_OFFSET 7
> +
> #define FEC_ATIME_CTRL 0x400
> #define FEC_ATIME 0x404
> #define FEC_ATIME_EVT_OFFSET 0x408
> @@ -69,9 +87,162 @@
> #define FEC_ATIME_INC 0x414
> #define FEC_TS_TIMESTAMP 0x418
>
> +#define FEC_TGSR 0x604
> +#define FEC_TCSR(n) (0x608 + n * 0x08)
> +#define FEC_TCCR(n) (0x60C + n * 0x08)
> +#define MAX_TIMER_CHANNEL 3
> +#define FEC_TMODE_TOGGLE 0x05
> +#define FEC_HIGH_PULSE 0x0F
> +
> #define FEC_CC_MULT (1 << 31)
> #define FEC_COUNTER_PERIOD (1 << 31)
> #define FEC_T_PERIOD_ONE_SEC (1000000000UL)
> +#define PPS_OUPUT_RELOAD_PERIOD FEC_T_PERIOD_ONE_SEC
> +
> +/**
> + * fec_ptp_enable_pps
> + * @fep: the fec_enet_private structure handle
> + * @enable: enable the channel pps output
> + *
> + * This function enble the PPS ouput on the timer channel.
> + */
> +static int fec_ptp_enable_pps(struct fec_enet_private *fep, uint enable)
> +{
> + unsigned long flags;
> + u32 val, tempval;
> + int inc;
> + struct timespec ts;
> + u64 ns;
> + u32 remainder;
> + val = 0;
> +
> + if (fep->pps_channel == -1 || fep->pps_channel > MAX_TIMER_CHANNEL) {
> + dev_err(&fep->pdev->dev, "Invalid pps channel\n");
> + return -EINVAL;
> + }
> +
> + if (!(fep->hwts_tx_en || fep->hwts_rx_en)) {
> + dev_err(&fep->pdev->dev, "No ptp stack is running\n");
> + return -EINVAL;
> + }
> +
> + if (fep->pps_enable == enable)
> + return 0;
> +
> + fep->reload_period = PPS_OUPUT_RELOAD_PERIOD;
> + inc = FEC_T_PERIOD_ONE_SEC / clk_get_rate(fep->clk_ptp);
> +
> + spin_lock_irqsave(&fep->tmreg_lock, flags);
> +
> + if (enable) {
> + /*
> + * clear capture or output compare interrupt status if have.
> + */
> + writel(FEC_T_TF_MASK, fep->hwp + FEC_TCSR(fep->pps_channel));
> +
> + /*
> + * It is recommended to doulbe check the TMODE field in the
> + * TCSR register to be cleared before the first compare counter
> + * is written into TCCR register. Just add a double check.
> + */
> + val = readl(fep->hwp + FEC_TCSR(fep->pps_channel));
> + do {
> + val &= ~(FEC_T_TMODE_MASK);
> + writel(val, fep->hwp + FEC_TCSR(fep->pps_channel));
> + val = readl(fep->hwp + FEC_TCSR(fep->pps_channel));
> + } while (val & FEC_T_TMODE_MASK);
> +
> + /*
> + * Dummy read counter to update the counter
> + */
> + timecounter_read(&fep->tc);
> + /*
> + * linux ptp is running. We want to find the first compare event
^^^^^^^^^^^^^^^^^^^^
What does this mean?
> + * in the next second point. So we need to know what the ptp time
> + * is now and how many nanoseconds is ahead to get next second.
> + * The remaining nanosecond ahead before the next second would be
> + * FEC_T_PERIOD_ONE_SEC - ts.tv_nsec. Add the remaining nanoseconds
> + * to current timer would be next second.
> + */
> + tempval = readl(fep->hwp + FEC_ATIME_CTRL);
> + tempval |= FEC_T_CTRL_CAPTURE;
> + writel(tempval, fep->hwp + FEC_ATIME_CTRL);
> +
> + tempval = readl(fep->hwp + FEC_ATIME);
> + /*
> + * Converse the ptp local counter to 1588 timestamp
^^^^^^^^
Convert?
> + */
> + ns = timecounter_cyc2time(&fep->tc, tempval);
> + ts.tv_sec = div_u64_rem(ns, 1000000000ULL, &remainder);
> + ts.tv_nsec = remainder;
> +
> + /*
> + * The tempval is less than 3 seconds, and so val is less than
> + * 4 seconds. No overflow for 32bit calculation.
> + */
> + val = FEC_T_PERIOD_ONE_SEC - (u32)ts.tv_nsec + tempval;
> +
> + /* Need to consider the situation that the current time is
> + * very close to the second point, which means FEC_T_PERIOD_ONE_SEC
> + * - ts.tv_nsec is close to be zero(For example 20ns); Since the timer
> + * is still running when we calculate the first compare event, it is
> + * possible that the remaining nanoseonds run out before the compare
> + * counter is calculated and written into TCCR register. To avoid
> + * this possibility, we will set the compare event to be the next
> + * of next second. The current setting is 31-bit timer and wrap
> + * around over 2 seconds. So it is okay to set the next of next
> + * seond for the timer.
> + */
> + val += FEC_T_PERIOD_ONE_SEC;
> +
> + /*
> + * We add (2 *FEC_T_PERIOD_ONE_SEC - (u32)ts.tv_nsec) to current
> + * ptp counter, which maybe cause 32-bit wrap. Since the
> + * (FEC_T_PERIOD_ONE_SEC - (u32)ts.tv_nsec) is less than 2 second.
> + * We can ensure the wrap will not cause issue. If the offset
> + * is bigger than fep->cc.mask would be a error.
> + */
> + val &= fep->cc.mask;
> + writel(val, fep->hwp + FEC_TCCR(fep->pps_channel));
> +
> + /*
> + * Calculate the second the compare event timestamp.
> + */
> + fep->next_counter = (val + fep->reload_period) & fep->cc.mask;
> +
> + /*
> + * Enable compare event when overflow
> + */
> + val = readl(fep->hwp + FEC_ATIME_CTRL);
> + val |= FEC_T_CTRL_PINPER;
> + writel(val, fep->hwp + FEC_ATIME_CTRL);
> +
> + /*
> + * Compare channel setting.
> + */
> + val = readl(fep->hwp + FEC_TCSR(fep->pps_channel));
> + val |= (1 << FEC_T_TF_OFFSET | 1 << FEC_T_TIE_OFFSET);
> + val &= ~(1 << FEC_T_TDRE_OFFSET);
> + val &= ~(FEC_T_TMODE_MASK);
> + val |= (FEC_HIGH_PULSE << FEC_T_TMODE_OFFSET);
> + writel(val, fep->hwp + FEC_TCSR(fep->pps_channel));
> +
> + /*
> + * Write the second compare event timestamp and calculate
> + * the third timestamp. Refer the TCCR register detail in the spec.
> + */
> + writel(fep->next_counter, fep->hwp + FEC_TCCR(fep->pps_channel));
> + fep->next_counter = (fep->next_counter + fep->reload_period) & fep->cc.mask;
> + } else {
> + writel(0, fep->hwp + FEC_TCSR(fep->pps_channel));
> + }
> +
> + fep->pps_enable = enable;
> + spin_unlock_irqrestore(&fep->tmreg_lock, flags);
> +
> + return 0;
> +}
> +
> /**
> * fec_ptp_read - read raw cycle counter (to be used by time counter)
> * @cc: the cyclecounter structure
> @@ -322,6 +493,15 @@ static int fec_ptp_settime(struct ptp_clock_info *ptp,
> static int fec_ptp_enable(struct ptp_clock_info *ptp,
> struct ptp_clock_request *rq, int on)
> {
> + struct fec_enet_private *fep =
> + container_of(ptp, struct fec_enet_private, ptp_caps);
> + int ret = 0;
> +
> + if (rq->type == PTP_CLK_REQ_PPS) {
> + ret = fec_ptp_enable_pps(fep, on);
> +
> + return ret;
> + }
> return -EOPNOTSUPP;
> }
>
> @@ -427,6 +607,8 @@ void fec_ptp_init(struct platform_device *pdev)
> {
> struct net_device *ndev = platform_get_drvdata(pdev);
> struct fec_enet_private *fep = netdev_priv(ndev);
> + struct device_node *np = pdev->dev.of_node;
> + int err;
>
> fep->ptp_caps.owner = THIS_MODULE;
> snprintf(fep->ptp_caps.name, 16, "fec ptp");
> @@ -436,7 +618,7 @@ void fec_ptp_init(struct platform_device *pdev)
> fep->ptp_caps.n_ext_ts = 0;
> fep->ptp_caps.n_per_out = 0;
> fep->ptp_caps.n_pins = 0;
> - fep->ptp_caps.pps = 0;
> + fep->ptp_caps.pps = 1;
> fep->ptp_caps.adjfreq = fec_ptp_adjfreq;
> fep->ptp_caps.adjtime = fec_ptp_adjtime;
> fep->ptp_caps.gettime = fec_ptp_gettime;
> @@ -444,6 +626,10 @@ void fec_ptp_init(struct platform_device *pdev)
> fep->ptp_caps.enable = fec_ptp_enable;
>
> fep->cycle_speed = clk_get_rate(fep->clk_ptp);
> + err = of_property_read_u32(np, "pps-channel",
> + &fep->pps_channel);
Please do not make another DT property for this.
Instead, use the PTP_PIN_SET/GETFUNC interface. You can add a new
enumeration value to ptp_pin_function, like PTP_PF_PPS.
Thanks,
Richard
> + if (err)
> + fep->pps_channel = -1;
>
> spin_lock_init(&fep->tmreg_lock);
>
> @@ -459,3 +645,38 @@ void fec_ptp_init(struct platform_device *pdev)
>
> schedule_delayed_work(&fep->time_keep, HZ);
> }
> +
> +/**
> + * fec_ptp_check_pps_event
> + * @fep: the fec_enet_private structure handle
> + *
> + * This function check the pps event and reload the timer compare counter.
> + */
> +uint fec_ptp_check_pps_event(struct fec_enet_private *fep)
> +{
> + u32 val;
> + u8 channel = fep->pps_channel;
> + struct ptp_clock_event event;
> +
> + val = readl(fep->hwp + FEC_TCSR(channel));
> + if (val & FEC_T_TF_MASK) {
> + /*
> + * Write the next next compare(not the next according the spec) value to the register
> + */
> + writel(fep->next_counter, fep->hwp + FEC_TCCR(channel));
> + do {
> + writel(val, fep->hwp + FEC_TCSR(channel));
> + } while (readl(fep->hwp + FEC_TCSR(channel)) & FEC_T_TF_MASK);
> +
> + /*
> + * Update the counter;
> + */
> + fep->next_counter = (fep->next_counter + fep->reload_period) & fep->cc.mask;
> +
> + event.type = PTP_CLOCK_PPS;
> + ptp_clock_event(fep->ptp_clock, &event);
> + return 1;
> + }
> +
> + return 0;
> +}
> --
> 1.9.1
>
^ permalink raw reply
* Re: [net-next PATCH 1/1 V4] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE
From: Tom Herbert @ 2014-09-25 14:40 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Jesper Dangaard Brouer, Eric Dumazet, Linux Netdev List,
David S. Miller, Alexander Duyck,
Toke Høiland-Jørgensen, Florian Westphal, Dave Taht,
John Fastabend, Daniel Borkmann, Hannes Frederic Sowa
In-Reply-To: <54240F34.1050707@mojatatu.com>
On Thu, Sep 25, 2014 at 5:48 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 09/25/14 04:25, Jesper Dangaard Brouer wrote:
>>
>> On Wed, 24 Sep 2014 18:13:57 -0400
>
>
>> I've done measurements with netperf-wrapper:
>>
>> http://netoptimizer.blogspot.dk/2014/09/mini-tutorial-for-netperf-wrapper-setup.html
>>
>> I have already previously posted my measurements here:
>> http://people.netfilter.org/hawk/qdisc/
>> http://people.netfilter.org/hawk/qdisc/measure01/
>> http://people.netfilter.org/hawk/qdisc/experiment01/
>>
>
> Theres a lot of data there to digest; all good looking.
> I will try to pay attention to detail and get back to you.
> What you have on those urls is fit for a paper, but what someone
> like me (with ADD) needs is a summary somewhere maybe in the commit
> logs.
>
>> Please, see my previous mail where I described each graph.
>>
>
> Is this patch 0?
> I think a simple statement in the commit log that no cats
> were harmed ^W^W^W performance was affected. A paragraph
> at most but if you want to do more, DaveM actually has no
> problems if you write the details of a novel in patch 0.
>
+1
A few test results in patch 0 are good. I like to have results for
with and without patch. These should two things: 1) Any regressions
caused by the patch 2) Performance gains (in that order of importance
:-) ). There doesn't need to be a lot here, just something reasonably
representative, simple, and should be easily reproducible. My
expectation in bulk dequeue is that we should see no obvious
regression and hopefully an improvement in CPU utilization-- are you
able to verify this?
> cheers,
> jamal
^ 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