* [PATCH net-next v2 1/2] net: l3mdev: Add hook in ip and ipv6
From: David Ahern @ 2016-05-07 1:49 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
In-Reply-To: <1462585781-9146-1-git-send-email-dsa@cumulusnetworks.com>
Currently the VRF driver uses the rx_handler to switch the skb device
to the VRF device. Switching the dev prior to the ip / ipv6 layer
means the VRF driver has to duplicate IP/IPv6 processing which adds
overhead and makes features such as retaining the ingress device index
more complicated than necessary.
This patch moves the hook to the L3 layer just after the first NF_HOOK
for PRE_ROUTING. This location makes exposing the original ingress device
trivial (next patch) and allows adding other NF_HOOKs to the VRF driver
in the future.
dev_queue_xmit_nit is exported so that the VRF driver can cycle the skb
with the switched device through the packet taps to maintain current
behavior (tcpdump can be used on either the vrf device or the enslaved
devices).
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
v2
- add skb_l3mdev_slave helper for inet6_iif and tcp_v6_iif rather
than open coding the if case. Added benefit that the change compiles
out if CONFIG_NET_L3_MASTER_DEV is not enabled.
drivers/net/vrf.c | 188 ++++++++++++++++++++++------------------------
include/linux/ipv6.h | 17 ++++-
include/linux/netdevice.h | 2 +
include/net/l3mdev.h | 43 +++++++++++
include/net/tcp.h | 4 +-
net/core/dev.c | 3 +-
net/ipv4/ip_input.c | 7 ++
net/ipv6/ip6_input.c | 7 ++
8 files changed, 170 insertions(+), 101 deletions(-)
diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index 4b2461ae5d3b..0e2a58506a35 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -42,9 +42,6 @@
#define DRV_NAME "vrf"
#define DRV_VERSION "1.0"
-#define vrf_master_get_rcu(dev) \
- ((struct net_device *)rcu_dereference(dev->rx_handler_data))
-
struct net_vrf {
struct rtable *rth;
struct rt6_info *rt6;
@@ -60,90 +57,12 @@ struct pcpu_dstats {
struct u64_stats_sync syncp;
};
-/* neighbor handling is done with actual device; do not want
- * to flip skb->dev for those ndisc packets. This really fails
- * for multiple next protocols (e.g., NEXTHDR_HOP). But it is
- * a start.
- */
-#if IS_ENABLED(CONFIG_IPV6)
-static bool check_ipv6_frame(const struct sk_buff *skb)
-{
- const struct ipv6hdr *ipv6h;
- struct ipv6hdr _ipv6h;
- bool rc = true;
-
- ipv6h = skb_header_pointer(skb, 0, sizeof(_ipv6h), &_ipv6h);
- if (!ipv6h)
- goto out;
-
- if (ipv6h->nexthdr == NEXTHDR_ICMP) {
- const struct icmp6hdr *icmph;
- struct icmp6hdr _icmph;
-
- icmph = skb_header_pointer(skb, sizeof(_ipv6h),
- sizeof(_icmph), &_icmph);
- if (!icmph)
- goto out;
-
- switch (icmph->icmp6_type) {
- case NDISC_ROUTER_SOLICITATION:
- case NDISC_ROUTER_ADVERTISEMENT:
- case NDISC_NEIGHBOUR_SOLICITATION:
- case NDISC_NEIGHBOUR_ADVERTISEMENT:
- case NDISC_REDIRECT:
- rc = false;
- break;
- }
- }
-
-out:
- return rc;
-}
-#else
-static bool check_ipv6_frame(const struct sk_buff *skb)
-{
- return false;
-}
-#endif
-
-static bool is_ip_rx_frame(struct sk_buff *skb)
-{
- switch (skb->protocol) {
- case htons(ETH_P_IP):
- return true;
- case htons(ETH_P_IPV6):
- return check_ipv6_frame(skb);
- }
- return false;
-}
-
static void vrf_tx_error(struct net_device *vrf_dev, struct sk_buff *skb)
{
vrf_dev->stats.tx_errors++;
kfree_skb(skb);
}
-/* note: already called with rcu_read_lock */
-static rx_handler_result_t vrf_handle_frame(struct sk_buff **pskb)
-{
- struct sk_buff *skb = *pskb;
-
- if (is_ip_rx_frame(skb)) {
- struct net_device *dev = vrf_master_get_rcu(skb->dev);
- struct pcpu_dstats *dstats = this_cpu_ptr(dev->dstats);
-
- u64_stats_update_begin(&dstats->syncp);
- dstats->rx_pkts++;
- dstats->rx_bytes += skb->len;
- u64_stats_update_end(&dstats->syncp);
-
- skb->dev = dev;
-
- return RX_HANDLER_ANOTHER;
- }
- return RX_HANDLER_PASS;
-}
-
static struct rtnl_link_stats64 *vrf_get_stats64(struct net_device *dev,
struct rtnl_link_stats64 *stats)
{
@@ -506,28 +425,14 @@ static int do_vrf_add_slave(struct net_device *dev, struct net_device *port_dev)
{
int ret;
- /* register the packet handler for slave ports */
- ret = netdev_rx_handler_register(port_dev, vrf_handle_frame, dev);
- if (ret) {
- netdev_err(port_dev,
- "Device %s failed to register rx_handler\n",
- port_dev->name);
- goto out_fail;
- }
-
ret = netdev_master_upper_dev_link(port_dev, dev, NULL, NULL);
if (ret < 0)
- goto out_unregister;
+ return ret;
port_dev->priv_flags |= IFF_L3MDEV_SLAVE;
cycle_netdev(port_dev);
return 0;
-
-out_unregister:
- netdev_rx_handler_unregister(port_dev);
-out_fail:
- return ret;
}
static int vrf_add_slave(struct net_device *dev, struct net_device *port_dev)
@@ -544,8 +449,6 @@ static int do_vrf_del_slave(struct net_device *dev, struct net_device *port_dev)
netdev_upper_dev_unlink(port_dev, dev);
port_dev->priv_flags &= ~IFF_L3MDEV_SLAVE;
- netdev_rx_handler_unregister(port_dev);
-
cycle_netdev(port_dev);
return 0;
@@ -668,6 +571,94 @@ static int vrf_get_saddr(struct net_device *dev, struct flowi4 *fl4)
}
#if IS_ENABLED(CONFIG_IPV6)
+/* neighbor handling is done with actual device; do not want
+ * to flip skb->dev for those ndisc packets. This really fails
+ * for multiple next protocols (e.g., NEXTHDR_HOP). But it is
+ * a start.
+ */
+static bool ipv6_ndisc_frame(const struct sk_buff *skb)
+{
+ const struct ipv6hdr *ipv6h = (struct ipv6hdr *)skb->data;
+ size_t hlen = sizeof(*ipv6h);
+ bool rc = false;
+
+ if (ipv6h->nexthdr == NEXTHDR_ICMP) {
+ const struct icmp6hdr *icmph;
+
+ if (skb->len < hlen + sizeof(*icmph))
+ goto out;
+
+ icmph = (struct icmp6hdr *)(skb->data + sizeof(*ipv6h));
+ switch (icmph->icmp6_type) {
+ case NDISC_ROUTER_SOLICITATION:
+ case NDISC_ROUTER_ADVERTISEMENT:
+ case NDISC_NEIGHBOUR_SOLICITATION:
+ case NDISC_NEIGHBOUR_ADVERTISEMENT:
+ case NDISC_REDIRECT:
+ rc = true;
+ break;
+ }
+ }
+
+out:
+ return rc;
+}
+
+static struct sk_buff *vrf_ip6_rcv(struct net_device *vrf_dev,
+ struct sk_buff *skb)
+{
+ /* if packet is NDISC keep the ingress interface */
+ if (!ipv6_ndisc_frame(skb)) {
+ skb->dev = vrf_dev;
+ skb->skb_iif = vrf_dev->ifindex;
+
+ skb_push(skb, skb->mac_len);
+ dev_queue_xmit_nit(skb, vrf_dev);
+ skb_pull(skb, skb->mac_len);
+
+ IP6CB(skb)->flags |= IP6SKB_L3SLAVE;
+ }
+
+ return skb;
+}
+
+#else
+static struct sk_buff *vrf_ip6_rcv(struct net_device *vrf_dev,
+ struct sk_buff *skb)
+{
+ return skb;
+}
+#endif
+
+static struct sk_buff *vrf_ip_rcv(struct net_device *vrf_dev,
+ struct sk_buff *skb)
+{
+ skb->dev = vrf_dev;
+ skb->skb_iif = vrf_dev->ifindex;
+
+ skb_push(skb, skb->mac_len);
+ dev_queue_xmit_nit(skb, vrf_dev);
+ skb_pull(skb, skb->mac_len);
+
+ return skb;
+}
+
+/* called with rcu lock held */
+static struct sk_buff *vrf_l3_rcv(struct net_device *vrf_dev,
+ struct sk_buff *skb,
+ u16 proto)
+{
+ switch (proto) {
+ case AF_INET:
+ return vrf_ip_rcv(vrf_dev, skb);
+ case AF_INET6:
+ return vrf_ip6_rcv(vrf_dev, skb);
+ }
+
+ return skb;
+}
+
+#if IS_ENABLED(CONFIG_IPV6)
static struct dst_entry *vrf_get_rt6_dst(const struct net_device *dev,
const struct flowi6 *fl6)
{
@@ -688,6 +679,7 @@ static const struct l3mdev_ops vrf_l3mdev_ops = {
.l3mdev_fib_table = vrf_fib_table,
.l3mdev_get_rtable = vrf_get_rtable,
.l3mdev_get_saddr = vrf_get_saddr,
+ .l3mdev_l3_rcv = vrf_l3_rcv,
#if IS_ENABLED(CONFIG_IPV6)
.l3mdev_get_rt6_dst = vrf_get_rt6_dst,
#endif
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index 58d6e158755f..5c91b0b055d4 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -118,14 +118,29 @@ struct inet6_skb_parm {
#define IP6SKB_ROUTERALERT 8
#define IP6SKB_FRAGMENTED 16
#define IP6SKB_HOPBYHOP 32
+#define IP6SKB_L3SLAVE 64
};
+#if defined(CONFIG_NET_L3_MASTER_DEV)
+static inline bool skb_l3mdev_slave(__u16 flags)
+{
+ return flags & IP6SKB_L3SLAVE;
+}
+#else
+static inline bool skb_l3mdev_slave(__u16 flags)
+{
+ return false;
+}
+#endif
+
#define IP6CB(skb) ((struct inet6_skb_parm*)((skb)->cb))
#define IP6CBMTU(skb) ((struct ip6_mtuinfo *)((skb)->cb))
static inline int inet6_iif(const struct sk_buff *skb)
{
- return IP6CB(skb)->iif;
+ bool l3_slave = skb_l3mdev_slave(IP6CB(skb)->flags);
+
+ return l3_slave ? skb->skb_iif : IP6CB(skb)->iif;
}
struct tcp6_request_sock {
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 63580e6d0df4..c2f5112f08f7 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3258,6 +3258,8 @@ int dev_forward_skb(struct net_device *dev, struct sk_buff *skb);
bool is_skb_forwardable(const struct net_device *dev,
const struct sk_buff *skb);
+void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev);
+
extern int netdev_budget;
/* Called by rtnetlink.c:rtnl_unlock() */
diff --git a/include/net/l3mdev.h b/include/net/l3mdev.h
index c43a9c73de5e..19d8171d7cbb 100644
--- a/include/net/l3mdev.h
+++ b/include/net/l3mdev.h
@@ -25,6 +25,8 @@
struct l3mdev_ops {
u32 (*l3mdev_fib_table)(const struct net_device *dev);
+ struct sk_buff * (*l3mdev_l3_rcv)(struct net_device *dev,
+ struct sk_buff *skb, u16 proto);
/* IPv4 ops */
struct rtable * (*l3mdev_get_rtable)(const struct net_device *dev,
@@ -177,6 +179,35 @@ struct dst_entry *l3mdev_rt6_dst_by_oif(struct net *net,
return dst;
}
+static inline
+struct sk_buff *l3mdev_l3_rcv(struct sk_buff *skb, u16 proto)
+{
+ struct net_device *master = NULL;
+
+ if (netif_is_l3_slave(skb->dev))
+ master = netdev_master_upper_dev_get_rcu(skb->dev);
+
+ else if (netif_is_l3_master(skb->dev))
+ master = skb->dev;
+
+ if (master && master->l3mdev_ops->l3mdev_l3_rcv)
+ skb = master->l3mdev_ops->l3mdev_l3_rcv(master, skb, proto);
+
+ return skb;
+}
+
+static inline
+struct sk_buff *l3mdev_ip_rcv(struct sk_buff *skb)
+{
+ return l3mdev_l3_rcv(skb, AF_INET);
+}
+
+static inline
+struct sk_buff *l3mdev_ip6_rcv(struct sk_buff *skb)
+{
+ return l3mdev_l3_rcv(skb, AF_INET6);
+}
+
#else
static inline int l3mdev_master_ifindex_rcu(const struct net_device *dev)
@@ -244,6 +275,18 @@ struct dst_entry *l3mdev_rt6_dst_by_oif(struct net *net,
{
return NULL;
}
+
+static inline
+struct sk_buff *l3mdev_ip_rcv(struct sk_buff *skb)
+{
+ return skb;
+}
+
+static inline
+struct sk_buff *l3mdev_ip6_rcv(struct sk_buff *skb)
+{
+ return skb;
+}
#endif
#endif /* _NET_L3MDEV_H_ */
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 24ec80483805..264e8bb3d1ea 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -781,7 +781,9 @@ struct tcp_skb_cb {
*/
static inline int tcp_v6_iif(const struct sk_buff *skb)
{
- return TCP_SKB_CB(skb)->header.h6.iif;
+ bool l3_slave = skb_l3mdev_slave(TCP_SKB_CB(skb)->header.h6.flags);
+
+ return l3_slave ? skb->skb_iif : TCP_SKB_CB(skb)->header.h6.iif;
}
#endif
diff --git a/net/core/dev.c b/net/core/dev.c
index e98ba63fe280..51a8bf28a3e0 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1850,7 +1850,7 @@ static inline bool skb_loop_sk(struct packet_type *ptype, struct sk_buff *skb)
* taps currently in use.
*/
-static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
+void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
{
struct packet_type *ptype;
struct sk_buff *skb2 = NULL;
@@ -1907,6 +1907,7 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
pt_prev->func(skb2, skb->dev, pt_prev, skb->dev);
rcu_read_unlock();
}
+EXPORT_SYMBOL_GPL(dev_queue_xmit_nit);
/**
* netif_setup_tc - Handle tc mappings on real_num_tx_queues change
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 751c0658e194..37375eedeef9 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -313,6 +313,13 @@ static int ip_rcv_finish(struct net *net, struct sock *sk, struct sk_buff *skb)
const struct iphdr *iph = ip_hdr(skb);
struct rtable *rt;
+ /* if ingress device is enslaved to an L3 master device pass the
+ * skb to its handler for processing
+ */
+ skb = l3mdev_ip_rcv(skb);
+ if (!skb)
+ return NET_RX_SUCCESS;
+
if (net->ipv4.sysctl_ip_early_demux &&
!skb_dst(skb) &&
!skb->sk &&
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index 6ed56012005d..f185cbcda114 100644
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -49,6 +49,13 @@
int ip6_rcv_finish(struct net *net, struct sock *sk, struct sk_buff *skb)
{
+ /* if ingress device is enslaved to an L3 master device pass the
+ * skb to its handler for processing
+ */
+ skb = l3mdev_ip6_rcv(skb);
+ if (!skb)
+ return NET_RX_SUCCESS;
+
if (net->ipv4.sysctl_ip_early_demux && !skb_dst(skb) && skb->sk == NULL) {
const struct inet6_protocol *ipprot;
--
2.1.4
^ permalink raw reply related
* [PATCH net-next 2/2] net: original ingress device index in PKTINFO
From: David Ahern @ 2016-05-07 1:49 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
In-Reply-To: <1462585781-9146-1-git-send-email-dsa@cumulusnetworks.com>
Applications such as OSPF and BFD need the original ingress device not
the VRF device; the latter can be derived from the former. To that end
add the skb_iif to inet_skb_parm and set it in ipv4 code after clearing
the skb control buffer similar to IPv6. From there the pktinfo can just
pull it from cb with the PKTINFO_SKB_CB cast.
The previous patch moving the skb->dev change to L3 means nothing else
is needed for IPv6; it just works.
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
include/net/ip.h | 1 +
net/ipv4/ip_input.c | 1 +
net/ipv4/ip_sockglue.c | 7 ++++++-
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/net/ip.h b/include/net/ip.h
index 247ac82e9cf2..37165fba3741 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -36,6 +36,7 @@
struct sock;
struct inet_skb_parm {
+ int iif;
struct ip_options opt; /* Compiled IP options */
unsigned char flags;
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 37375eedeef9..4b351af3e67b 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -478,6 +478,7 @@ int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt,
/* Remove any debris in the socket control block */
memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
+ IPCB(skb)->iif = skb->skb_iif;
/* Must drop socket now because of tproxy. */
skb_orphan(skb);
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index bdb222c0c6a2..5805762d7fc7 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1193,7 +1193,12 @@ void ipv4_pktinfo_prepare(const struct sock *sk, struct sk_buff *skb)
ipv6_sk_rxinfo(sk);
if (prepare && skb_rtable(skb)) {
- pktinfo->ipi_ifindex = inet_iif(skb);
+ /* skb->cb is overloaded: prior to this point it is IP{6}CB
+ * which has interface index (iif) as the first member of the
+ * underlying inet{6}_skb_parm struct. This code then overlays
+ * PKTINFO_SKB_CB and in_pktinfo also has iif as the first
+ * element so the iif is picked up from the prior IPCB
+ */
pktinfo->ipi_spec_dst.s_addr = fib_compute_spec_dst(skb);
} else {
pktinfo->ipi_ifindex = 0;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling
From: Tom Herbert @ 2016-05-07 1:57 UTC (permalink / raw)
To: Alexander Duyck; +Cc: David Miller, Netdev, Kernel Team
In-Reply-To: <CAKgT0UdvZbDsDewsGRvMO93OZNSSXKfWaT7RvWkb6DQaG9jvyA@mail.gmail.com>
On Fri, May 6, 2016 at 6:09 PM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Fri, May 6, 2016 at 3:11 PM, Tom Herbert <tom@herbertland.com> wrote:
>> This patch set:
>> - Fixes GRE6 to process translate flags correctly from configuration
>> - Adds support for GSO and GRO for ip6ip6 and ip4ip6
>> - Add support for FOU and GUE in IPv6
>> - Support GRE, ip6ip6 and ip4ip6 over FOU/GUE
>> - Fixes ip6_input to deal with UDP encapsulations
>> - Some other minor fixes
>>
>> v2:
>> - Removed a check of GSO types in MPLS
>> - Define GSO type SKB_GSO_IPXIP6 and SKB_GSO_IPXIP4 (based on input
>> from Alexander)
>> - Don't define GSO types specifally for IP6IP6 and IP4IP6, above
>> fix makes that uncessary
>> - Don't bother clearing encapsulation flag in UDP tunnel segment
>> (another item suggested by Alexander).
>>
>> v3:
>> - Address some minor comments from Alexander
>>
>> Tested:
>> Tested a variety of case, but not the full matrix (which is quite
>> large now). Most of the obivous cases (e.g. GRE) work fine. Still
>> some issues probably with GSO/GRO being effective in all cases.
>>
>> - IPv4/GRE/GUE/IPv6 with RCO
>> 1 TCP_STREAM
>> 6616 Mbps
>> 200 TCP_RR
>> 1244043 tps
>> 141/243/446 90/95/99% latencies
>> 86.61% CPU utilization
>> - IPv6/GRE/GUE/IPv6 with RCO
>> 1 TCP_STREAM
>> 6940 Mbps
>> 200 TCP_RR
>> 1270903 tps
>> 138/236/440 90/95/99% latencies
>> 87.51% CPU utilization
>>
>> - IP6IP6
>> 1 TCP_STREAM
>> 2576 Mbps
>> 200 TCP_RR
>> 498981 tps
>> 388/498/631 90/95/99% latencies
>> 19.75% CPU utilization (1 CPU saturated)
>>
>> - IP6IP6/GUE/IPv6 with RCO
>> 1 TCP_STREAM
>> 1854 Mbps
>> 200 TCP_RR
>> 1233818 tps
>> 143/244/451 90/95/99% latencies
>> 87.57 CPU utilization
>>
>> - IP4IP6
>> 1 TCP_STREAM
>> 200 TCP_RR
>> 763774 tps
>> 250/318/466 90/95/99% latencies
>> 35.25% CPU utilization (1 CPU saturated)
>>
>> - GRE with keyid
>> 200 TCP_RR
>> 744173 tps
>> 258/332/461 90/95/99% latencies
>> 34.59% CPU utilization (1 CPU saturated)
>
> So I tried testing your patch set and it looks like I cannot get GRE
> working for any netperf test. If I pop the patches off it is even
> worse since it looks like patch 3 fixes some tunnel flags issues, but
> still doesn't resolve all the issues introduced with b05229f44228
> ("gre6: Cleanup GREv6 transmit path, call common GRE functions").
> Reverting the entire patch seems to resolve the issues, but I will try
> to pick it apart tonight to see if I can find the other issues that
> weren't addressed in this patch series.
>
Can you give details about configuration, test you're running, and HW?
> - Alex
^ permalink raw reply
* Re: [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling
From: Alexander Duyck @ 2016-05-07 2:03 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Netdev, Kernel Team
In-Reply-To: <CALx6S36uA83qEoYw2daxHrpege0zyNO=5u0iJ9tZu=RaBAK8cA@mail.gmail.com>
On Fri, May 6, 2016 at 6:57 PM, Tom Herbert <tom@herbertland.com> wrote:
> On Fri, May 6, 2016 at 6:09 PM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> On Fri, May 6, 2016 at 3:11 PM, Tom Herbert <tom@herbertland.com> wrote:
>>> This patch set:
>>> - Fixes GRE6 to process translate flags correctly from configuration
>>> - Adds support for GSO and GRO for ip6ip6 and ip4ip6
>>> - Add support for FOU and GUE in IPv6
>>> - Support GRE, ip6ip6 and ip4ip6 over FOU/GUE
>>> - Fixes ip6_input to deal with UDP encapsulations
>>> - Some other minor fixes
>>>
>>> v2:
>>> - Removed a check of GSO types in MPLS
>>> - Define GSO type SKB_GSO_IPXIP6 and SKB_GSO_IPXIP4 (based on input
>>> from Alexander)
>>> - Don't define GSO types specifally for IP6IP6 and IP4IP6, above
>>> fix makes that uncessary
>>> - Don't bother clearing encapsulation flag in UDP tunnel segment
>>> (another item suggested by Alexander).
>>>
>>> v3:
>>> - Address some minor comments from Alexander
>>>
>>> Tested:
>>> Tested a variety of case, but not the full matrix (which is quite
>>> large now). Most of the obivous cases (e.g. GRE) work fine. Still
>>> some issues probably with GSO/GRO being effective in all cases.
>>>
>>> - IPv4/GRE/GUE/IPv6 with RCO
>>> 1 TCP_STREAM
>>> 6616 Mbps
>>> 200 TCP_RR
>>> 1244043 tps
>>> 141/243/446 90/95/99% latencies
>>> 86.61% CPU utilization
>>> - IPv6/GRE/GUE/IPv6 with RCO
>>> 1 TCP_STREAM
>>> 6940 Mbps
>>> 200 TCP_RR
>>> 1270903 tps
>>> 138/236/440 90/95/99% latencies
>>> 87.51% CPU utilization
>>>
>>> - IP6IP6
>>> 1 TCP_STREAM
>>> 2576 Mbps
>>> 200 TCP_RR
>>> 498981 tps
>>> 388/498/631 90/95/99% latencies
>>> 19.75% CPU utilization (1 CPU saturated)
>>>
>>> - IP6IP6/GUE/IPv6 with RCO
>>> 1 TCP_STREAM
>>> 1854 Mbps
>>> 200 TCP_RR
>>> 1233818 tps
>>> 143/244/451 90/95/99% latencies
>>> 87.57 CPU utilization
>>>
>>> - IP4IP6
>>> 1 TCP_STREAM
>>> 200 TCP_RR
>>> 763774 tps
>>> 250/318/466 90/95/99% latencies
>>> 35.25% CPU utilization (1 CPU saturated)
>>>
>>> - GRE with keyid
>>> 200 TCP_RR
>>> 744173 tps
>>> 258/332/461 90/95/99% latencies
>>> 34.59% CPU utilization (1 CPU saturated)
>>
>> So I tried testing your patch set and it looks like I cannot get GRE
>> working for any netperf test. If I pop the patches off it is even
>> worse since it looks like patch 3 fixes some tunnel flags issues, but
>> still doesn't resolve all the issues introduced with b05229f44228
>> ("gre6: Cleanup GREv6 transmit path, call common GRE functions").
>> Reverting the entire patch seems to resolve the issues, but I will try
>> to pick it apart tonight to see if I can find the other issues that
>> weren't addressed in this patch series.
>>
>
> Can you give details about configuration, test you're running, and HW?
The issue looks like it may be specific to ip6gretap. I'm running the
test over an i40e adapter, but it shouldn't make much difference. I'm
thinking it may have something to do with the MTU configuration as
that is one of the things I am noticing has changed between the
working and the broken version of the code.
- Alex
^ permalink raw reply
* Re: [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling
From: Tom Herbert @ 2016-05-07 2:11 UTC (permalink / raw)
To: Alexander Duyck; +Cc: David Miller, Netdev, Kernel Team
In-Reply-To: <CAKgT0UdM1aQF8cLWVLXMmXyJnMHkZUum8YyKsyCSVFvBALmyCA@mail.gmail.com>
On Fri, May 6, 2016 at 7:03 PM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Fri, May 6, 2016 at 6:57 PM, Tom Herbert <tom@herbertland.com> wrote:
>> On Fri, May 6, 2016 at 6:09 PM, Alexander Duyck
>> <alexander.duyck@gmail.com> wrote:
>>> On Fri, May 6, 2016 at 3:11 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>> This patch set:
>>>> - Fixes GRE6 to process translate flags correctly from configuration
>>>> - Adds support for GSO and GRO for ip6ip6 and ip4ip6
>>>> - Add support for FOU and GUE in IPv6
>>>> - Support GRE, ip6ip6 and ip4ip6 over FOU/GUE
>>>> - Fixes ip6_input to deal with UDP encapsulations
>>>> - Some other minor fixes
>>>>
>>>> v2:
>>>> - Removed a check of GSO types in MPLS
>>>> - Define GSO type SKB_GSO_IPXIP6 and SKB_GSO_IPXIP4 (based on input
>>>> from Alexander)
>>>> - Don't define GSO types specifally for IP6IP6 and IP4IP6, above
>>>> fix makes that uncessary
>>>> - Don't bother clearing encapsulation flag in UDP tunnel segment
>>>> (another item suggested by Alexander).
>>>>
>>>> v3:
>>>> - Address some minor comments from Alexander
>>>>
>>>> Tested:
>>>> Tested a variety of case, but not the full matrix (which is quite
>>>> large now). Most of the obivous cases (e.g. GRE) work fine. Still
>>>> some issues probably with GSO/GRO being effective in all cases.
>>>>
>>>> - IPv4/GRE/GUE/IPv6 with RCO
>>>> 1 TCP_STREAM
>>>> 6616 Mbps
>>>> 200 TCP_RR
>>>> 1244043 tps
>>>> 141/243/446 90/95/99% latencies
>>>> 86.61% CPU utilization
>>>> - IPv6/GRE/GUE/IPv6 with RCO
>>>> 1 TCP_STREAM
>>>> 6940 Mbps
>>>> 200 TCP_RR
>>>> 1270903 tps
>>>> 138/236/440 90/95/99% latencies
>>>> 87.51% CPU utilization
>>>>
>>>> - IP6IP6
>>>> 1 TCP_STREAM
>>>> 2576 Mbps
>>>> 200 TCP_RR
>>>> 498981 tps
>>>> 388/498/631 90/95/99% latencies
>>>> 19.75% CPU utilization (1 CPU saturated)
>>>>
>>>> - IP6IP6/GUE/IPv6 with RCO
>>>> 1 TCP_STREAM
>>>> 1854 Mbps
>>>> 200 TCP_RR
>>>> 1233818 tps
>>>> 143/244/451 90/95/99% latencies
>>>> 87.57 CPU utilization
>>>>
>>>> - IP4IP6
>>>> 1 TCP_STREAM
>>>> 200 TCP_RR
>>>> 763774 tps
>>>> 250/318/466 90/95/99% latencies
>>>> 35.25% CPU utilization (1 CPU saturated)
>>>>
>>>> - GRE with keyid
>>>> 200 TCP_RR
>>>> 744173 tps
>>>> 258/332/461 90/95/99% latencies
>>>> 34.59% CPU utilization (1 CPU saturated)
>>>
>>> So I tried testing your patch set and it looks like I cannot get GRE
>>> working for any netperf test. If I pop the patches off it is even
>>> worse since it looks like patch 3 fixes some tunnel flags issues, but
>>> still doesn't resolve all the issues introduced with b05229f44228
>>> ("gre6: Cleanup GREv6 transmit path, call common GRE functions").
>>> Reverting the entire patch seems to resolve the issues, but I will try
>>> to pick it apart tonight to see if I can find the other issues that
>>> weren't addressed in this patch series.
>>>
>>
>> Can you give details about configuration, test you're running, and HW?
>
> The issue looks like it may be specific to ip6gretap. I'm running the
> test over an i40e adapter, but it shouldn't make much difference. I'm
> thinking it may have something to do with the MTU configuration as
> that is one of the things I am noticing has changed between the
> working and the broken version of the code.
>
I'm not seeing any issue with configuring:
ip link add name tun8 type ip6gretap remote
2401:db00:20:911a:face:0:27:0 local 2401:db00:20:911a:face:0:25:0 ttl
225
MTU issues would not surprise me with IPv6 though. This is part of the
area of code that seems drastically different than what IPv4 is doing.
Tom
> - Alex
^ permalink raw reply
* Re: [PATCH v3 net-next 01/11] gso: Remove arbitrary checks for unsupported GSO
From: Alexander Duyck @ 2016-05-07 2:44 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Netdev, Kernel Team
In-Reply-To: <1462572726-566137-2-git-send-email-tom@herbertland.com>
On Fri, May 6, 2016 at 3:11 PM, Tom Herbert <tom@herbertland.com> wrote:
> diff --git a/net/mpls/mpls_gso.c b/net/mpls/mpls_gso.c
> index bbcf604..6de1e13 100644
> --- a/net/mpls/mpls_gso.c
> +++ b/net/mpls/mpls_gso.c
> @@ -26,15 +26,6 @@ static struct sk_buff *mpls_gso_segment(struct sk_buff *skb,
> netdev_features_t mpls_features;
> __be16 mpls_protocol;
>
> - if (unlikely(skb_shinfo(skb)->gso_type &
> - ~(SKB_GSO_TCPV4 |
> - SKB_GSO_TCPV6 |
> - SKB_GSO_UDP |
> - SKB_GSO_DODGY |
> - SKB_GSO_TCP_FIXEDID |
> - SKB_GSO_TCP_ECN)))
> - goto out;
> -
> /* Setup inner SKB. */
> mpls_protocol = skb->protocol;
> skb->protocol = skb->inner_protocol;
Actually I just noticed a build warning for this patch. I guess the
label out isn't used anywhere else so you should probably drop it for
the mpls_gso_segment function.
- Alex
^ permalink raw reply
* Re: [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling
From: Alexander Duyck @ 2016-05-07 3:03 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Netdev, Kernel Team
In-Reply-To: <CALx6S37MF5Q7mVurAZR0KPpu2Y-rSQrRPGY3TkSZOpZgkaCHmw@mail.gmail.com>
On Fri, May 6, 2016 at 7:11 PM, Tom Herbert <tom@herbertland.com> wrote:
> On Fri, May 6, 2016 at 7:03 PM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> On Fri, May 6, 2016 at 6:57 PM, Tom Herbert <tom@herbertland.com> wrote:
>>> On Fri, May 6, 2016 at 6:09 PM, Alexander Duyck
>>> <alexander.duyck@gmail.com> wrote:
>>>> On Fri, May 6, 2016 at 3:11 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>>> This patch set:
>>>>> - Fixes GRE6 to process translate flags correctly from configuration
>>>>> - Adds support for GSO and GRO for ip6ip6 and ip4ip6
>>>>> - Add support for FOU and GUE in IPv6
>>>>> - Support GRE, ip6ip6 and ip4ip6 over FOU/GUE
>>>>> - Fixes ip6_input to deal with UDP encapsulations
>>>>> - Some other minor fixes
>>>>>
>>>>> v2:
>>>>> - Removed a check of GSO types in MPLS
>>>>> - Define GSO type SKB_GSO_IPXIP6 and SKB_GSO_IPXIP4 (based on input
>>>>> from Alexander)
>>>>> - Don't define GSO types specifally for IP6IP6 and IP4IP6, above
>>>>> fix makes that uncessary
>>>>> - Don't bother clearing encapsulation flag in UDP tunnel segment
>>>>> (another item suggested by Alexander).
>>>>>
>>>>> v3:
>>>>> - Address some minor comments from Alexander
>>>>>
>>>>> Tested:
>>>>> Tested a variety of case, but not the full matrix (which is quite
>>>>> large now). Most of the obivous cases (e.g. GRE) work fine. Still
>>>>> some issues probably with GSO/GRO being effective in all cases.
>>>>>
>>>>> - IPv4/GRE/GUE/IPv6 with RCO
>>>>> 1 TCP_STREAM
>>>>> 6616 Mbps
>>>>> 200 TCP_RR
>>>>> 1244043 tps
>>>>> 141/243/446 90/95/99% latencies
>>>>> 86.61% CPU utilization
>>>>> - IPv6/GRE/GUE/IPv6 with RCO
>>>>> 1 TCP_STREAM
>>>>> 6940 Mbps
>>>>> 200 TCP_RR
>>>>> 1270903 tps
>>>>> 138/236/440 90/95/99% latencies
>>>>> 87.51% CPU utilization
>>>>>
>>>>> - IP6IP6
>>>>> 1 TCP_STREAM
>>>>> 2576 Mbps
>>>>> 200 TCP_RR
>>>>> 498981 tps
>>>>> 388/498/631 90/95/99% latencies
>>>>> 19.75% CPU utilization (1 CPU saturated)
>>>>>
>>>>> - IP6IP6/GUE/IPv6 with RCO
>>>>> 1 TCP_STREAM
>>>>> 1854 Mbps
>>>>> 200 TCP_RR
>>>>> 1233818 tps
>>>>> 143/244/451 90/95/99% latencies
>>>>> 87.57 CPU utilization
>>>>>
>>>>> - IP4IP6
>>>>> 1 TCP_STREAM
>>>>> 200 TCP_RR
>>>>> 763774 tps
>>>>> 250/318/466 90/95/99% latencies
>>>>> 35.25% CPU utilization (1 CPU saturated)
>>>>>
>>>>> - GRE with keyid
>>>>> 200 TCP_RR
>>>>> 744173 tps
>>>>> 258/332/461 90/95/99% latencies
>>>>> 34.59% CPU utilization (1 CPU saturated)
>>>>
>>>> So I tried testing your patch set and it looks like I cannot get GRE
>>>> working for any netperf test. If I pop the patches off it is even
>>>> worse since it looks like patch 3 fixes some tunnel flags issues, but
>>>> still doesn't resolve all the issues introduced with b05229f44228
>>>> ("gre6: Cleanup GREv6 transmit path, call common GRE functions").
>>>> Reverting the entire patch seems to resolve the issues, but I will try
>>>> to pick it apart tonight to see if I can find the other issues that
>>>> weren't addressed in this patch series.
>>>>
>>>
>>> Can you give details about configuration, test you're running, and HW?
>>
>> The issue looks like it may be specific to ip6gretap. I'm running the
>> test over an i40e adapter, but it shouldn't make much difference. I'm
>> thinking it may have something to do with the MTU configuration as
>> that is one of the things I am noticing has changed between the
>> working and the broken version of the code.
>>
> I'm not seeing any issue with configuring:
>
> ip link add name tun8 type ip6gretap remote
> 2401:db00:20:911a:face:0:27:0 local 2401:db00:20:911a:face:0:25:0 ttl
> 225
>
> MTU issues would not surprise me with IPv6 though. This is part of the
> area of code that seems drastically different than what IPv4 is doing.
I am also using a key.
ip link add $name type ip6gretap key $net \
local fec0::1 remote $addr6 ttl 225 dev $PF0
Does the device you are using support any kind of checksum offload for
inner headers on GRE tunnels? It looks like if I turn off checksums
and correct the MTU I can then send traffic without issues. I'd say
that the Tx cleanup probably introduced 3 regressions. The first one
you addressed in patch 3 which fixes the flags. The second being the
fact that the MTU is wrong, and the third being something that
apparently broke checksum and maybe segmentation offload for
ip6gretap.
Really I think the transmit path cleanup should have probably been
broken down into a set of patches rather than slamming it in all in
one block. I can spend some time next week trying to sort it out if
you don't have any hardware that supports GRE segmentation or checksum
offload. If worse comes to worse I will just try breaking the revert
down into a set of smaller patches so I can figure out exactly which
change broke things.
- Alex
^ permalink raw reply
* [PATCH net-next] tcp: replace cnt & rtt with struct in pkts_acked()
From: Lawrence Brakmo @ 2016-05-07 3:28 UTC (permalink / raw)
To: netdev; +Cc: Kernel Team, Neal Cardwell, Eric Dumazet, Yuchung Cheng
Replace 2 arguments (cnt and rtt) in the congestion control modules'
pkts_acked() function with a struct. This will allow adding more
information without having to modify existing congestion control
modules (tcp_nv in particular needs bytes in flight when packet
was sent).
As proposed by Neal Cardwell in his comments to the tcp_nv patch.
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
---
include/net/tcp.h | 7 ++++++-
net/ipv4/tcp_bic.c | 6 +++---
net/ipv4/tcp_cdg.c | 14 +++++++-------
net/ipv4/tcp_cubic.c | 6 +++---
net/ipv4/tcp_htcp.c | 10 +++++-----
net/ipv4/tcp_illinois.c | 20 ++++++++++----------
net/ipv4/tcp_input.c | 7 +++++--
net/ipv4/tcp_lp.c | 6 +++---
net/ipv4/tcp_vegas.c | 6 +++---
net/ipv4/tcp_vegas.h | 2 +-
net/ipv4/tcp_veno.c | 7 ++++---
net/ipv4/tcp_westwood.c | 7 ++++---
net/ipv4/tcp_yeah.c | 7 ++++---
13 files changed, 58 insertions(+), 47 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 24ec804..dc588c3 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -849,6 +849,11 @@ enum tcp_ca_ack_event_flags {
union tcp_cc_info;
+struct ack_sample {
+ u32 pkts_acked;
+ s32 rtt_us;
+};
+
struct tcp_congestion_ops {
struct list_head list;
u32 key;
@@ -872,7 +877,7 @@ struct tcp_congestion_ops {
/* new value of cwnd after loss (optional) */
u32 (*undo_cwnd)(struct sock *sk);
/* hook for packet ack accounting (optional) */
- void (*pkts_acked)(struct sock *sk, u32 num_acked, s32 rtt_us);
+ void (*pkts_acked)(struct sock *sk, const struct ack_sample *sample);
/* get info for inet_diag (optional) */
size_t (*get_info)(struct sock *sk, u32 ext, int *attr,
union tcp_cc_info *info);
diff --git a/net/ipv4/tcp_bic.c b/net/ipv4/tcp_bic.c
index fd1405d..f469f1b 100644
--- a/net/ipv4/tcp_bic.c
+++ b/net/ipv4/tcp_bic.c
@@ -197,15 +197,15 @@ static void bictcp_state(struct sock *sk, u8 new_state)
/* Track delayed acknowledgment ratio using sliding window
* ratio = (15*ratio + sample) / 16
*/
-static void bictcp_acked(struct sock *sk, u32 cnt, s32 rtt)
+static void bictcp_acked(struct sock *sk, const struct ack_sample *sample)
{
const struct inet_connection_sock *icsk = inet_csk(sk);
if (icsk->icsk_ca_state == TCP_CA_Open) {
struct bictcp *ca = inet_csk_ca(sk);
- cnt -= ca->delayed_ack >> ACK_RATIO_SHIFT;
- ca->delayed_ack += cnt;
+ ca->delayed_ack += sample->pkts_acked -
+ (ca->delayed_ack >> ACK_RATIO_SHIFT);
}
}
diff --git a/net/ipv4/tcp_cdg.c b/net/ipv4/tcp_cdg.c
index ccce8a5..03725b2 100644
--- a/net/ipv4/tcp_cdg.c
+++ b/net/ipv4/tcp_cdg.c
@@ -294,12 +294,12 @@ static void tcp_cdg_cong_avoid(struct sock *sk, u32 ack, u32 acked)
ca->shadow_wnd = max(ca->shadow_wnd, ca->shadow_wnd + incr);
}
-static void tcp_cdg_acked(struct sock *sk, u32 num_acked, s32 rtt_us)
+static void tcp_cdg_acked(struct sock *sk, const struct ack_sample *sample)
{
struct cdg *ca = inet_csk_ca(sk);
struct tcp_sock *tp = tcp_sk(sk);
- if (rtt_us <= 0)
+ if (sample->rtt_us <= 0)
return;
/* A heuristic for filtering delayed ACKs, adapted from:
@@ -307,20 +307,20 @@ static void tcp_cdg_acked(struct sock *sk, u32 num_acked, s32 rtt_us)
* delay and rate based TCP mechanisms." TR 100219A. CAIA, 2010.
*/
if (tp->sacked_out == 0) {
- if (num_acked == 1 && ca->delack) {
+ if (sample->pkts_acked == 1 && ca->delack) {
/* A delayed ACK is only used for the minimum if it is
* provenly lower than an existing non-zero minimum.
*/
- ca->rtt.min = min(ca->rtt.min, rtt_us);
+ ca->rtt.min = min(ca->rtt.min, sample->rtt_us);
ca->delack--;
return;
- } else if (num_acked > 1 && ca->delack < 5) {
+ } else if (sample->pkts_acked > 1 && ca->delack < 5) {
ca->delack++;
}
}
- ca->rtt.min = min_not_zero(ca->rtt.min, rtt_us);
- ca->rtt.max = max(ca->rtt.max, rtt_us);
+ ca->rtt.min = min_not_zero(ca->rtt.min, sample->rtt_us);
+ ca->rtt.max = max(ca->rtt.max, sample->rtt_us);
}
static u32 tcp_cdg_ssthresh(struct sock *sk)
diff --git a/net/ipv4/tcp_cubic.c b/net/ipv4/tcp_cubic.c
index 0ce946e..c99230e 100644
--- a/net/ipv4/tcp_cubic.c
+++ b/net/ipv4/tcp_cubic.c
@@ -437,21 +437,21 @@ static void hystart_update(struct sock *sk, u32 delay)
/* Track delayed acknowledgment ratio using sliding window
* ratio = (15*ratio + sample) / 16
*/
-static void bictcp_acked(struct sock *sk, u32 cnt, s32 rtt_us)
+static void bictcp_acked(struct sock *sk, const struct ack_sample *sample)
{
const struct tcp_sock *tp = tcp_sk(sk);
struct bictcp *ca = inet_csk_ca(sk);
u32 delay;
/* Some calls are for duplicates without timetamps */
- if (rtt_us < 0)
+ if (sample->rtt_us < 0)
return;
/* Discard delay samples right after fast recovery */
if (ca->epoch_start && (s32)(tcp_time_stamp - ca->epoch_start) < HZ)
return;
- delay = (rtt_us << 3) / USEC_PER_MSEC;
+ delay = (sample->rtt_us << 3) / USEC_PER_MSEC;
if (delay == 0)
delay = 1;
diff --git a/net/ipv4/tcp_htcp.c b/net/ipv4/tcp_htcp.c
index 82f0d9e..4a4d8e7 100644
--- a/net/ipv4/tcp_htcp.c
+++ b/net/ipv4/tcp_htcp.c
@@ -99,7 +99,7 @@ static inline void measure_rtt(struct sock *sk, u32 srtt)
}
static void measure_achieved_throughput(struct sock *sk,
- u32 pkts_acked, s32 rtt)
+ const struct ack_sample *sample)
{
const struct inet_connection_sock *icsk = inet_csk(sk);
const struct tcp_sock *tp = tcp_sk(sk);
@@ -107,10 +107,10 @@ static void measure_achieved_throughput(struct sock *sk,
u32 now = tcp_time_stamp;
if (icsk->icsk_ca_state == TCP_CA_Open)
- ca->pkts_acked = pkts_acked;
+ ca->pkts_acked = sample->pkts_acked;
- if (rtt > 0)
- measure_rtt(sk, usecs_to_jiffies(rtt));
+ if (sample->rtt_us > 0)
+ measure_rtt(sk, usecs_to_jiffies(sample->rtt_us));
if (!use_bandwidth_switch)
return;
@@ -122,7 +122,7 @@ static void measure_achieved_throughput(struct sock *sk,
return;
}
- ca->packetcount += pkts_acked;
+ ca->packetcount += sample->pkts_acked;
if (ca->packetcount >= tp->snd_cwnd - (ca->alpha >> 7 ? : 1) &&
now - ca->lasttime >= ca->minRTT &&
diff --git a/net/ipv4/tcp_illinois.c b/net/ipv4/tcp_illinois.c
index 2ab9bbb..77ad119 100644
--- a/net/ipv4/tcp_illinois.c
+++ b/net/ipv4/tcp_illinois.c
@@ -82,30 +82,30 @@ static void tcp_illinois_init(struct sock *sk)
}
/* Measure RTT for each ack. */
-static void tcp_illinois_acked(struct sock *sk, u32 pkts_acked, s32 rtt)
+static void tcp_illinois_acked(struct sock *sk, const struct ack_sample *sample)
{
struct illinois *ca = inet_csk_ca(sk);
- ca->acked = pkts_acked;
+ ca->acked = sample->pkts_acked;
/* dup ack, no rtt sample */
- if (rtt < 0)
+ if (sample->rtt_us < 0)
return;
/* ignore bogus values, this prevents wraparound in alpha math */
- if (rtt > RTT_MAX)
- rtt = RTT_MAX;
+ if (sample->rtt_us > RTT_MAX)
+ sample->rtt_us = RTT_MAX;
/* keep track of minimum RTT seen so far */
- if (ca->base_rtt > rtt)
- ca->base_rtt = rtt;
+ if (ca->base_rtt > sample->rtt_us)
+ ca->base_rtt = sample->rtt_us;
/* and max */
- if (ca->max_rtt < rtt)
- ca->max_rtt = rtt;
+ if (ca->max_rtt < sample->rtt_us)
+ ca->max_rtt = sample->rtt_us;
++ca->cnt_rtt;
- ca->sum_rtt += rtt;
+ ca->sum_rtt += sample->rtt_us;
}
/* Maximum queuing delay */
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index a914e06..ba8bf5c 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3248,8 +3248,11 @@ static int tcp_clean_rtx_queue(struct sock *sk, int prior_fackets,
tcp_rearm_rto(sk);
}
- if (icsk->icsk_ca_ops->pkts_acked)
- icsk->icsk_ca_ops->pkts_acked(sk, pkts_acked, ca_rtt_us);
+ if (icsk->icsk_ca_ops->pkts_acked) {
+ struct ack_sample sample = {pkts_acked, ca_rtt_us};
+
+ icsk->icsk_ca_ops->pkts_acked(sk, &sample);
+ }
#if FASTRETRANS_DEBUG > 0
WARN_ON((int)tp->sacked_out < 0);
diff --git a/net/ipv4/tcp_lp.c b/net/ipv4/tcp_lp.c
index 1e70fa8..c67ece1 100644
--- a/net/ipv4/tcp_lp.c
+++ b/net/ipv4/tcp_lp.c
@@ -260,13 +260,13 @@ static void tcp_lp_rtt_sample(struct sock *sk, u32 rtt)
* newReno in increase case.
* We work it out by following the idea from TCP-LP's paper directly
*/
-static void tcp_lp_pkts_acked(struct sock *sk, u32 num_acked, s32 rtt_us)
+static void tcp_lp_pkts_acked(struct sock *sk, const struct ack_sample *sample)
{
struct tcp_sock *tp = tcp_sk(sk);
struct lp *lp = inet_csk_ca(sk);
- if (rtt_us > 0)
- tcp_lp_rtt_sample(sk, rtt_us);
+ if (sample->rtt_us > 0)
+ tcp_lp_rtt_sample(sk, sample->rtt_us);
/* calc inference */
if (tcp_time_stamp > tp->rx_opt.rcv_tsecr)
diff --git a/net/ipv4/tcp_vegas.c b/net/ipv4/tcp_vegas.c
index 13951c4..4c4bac1 100644
--- a/net/ipv4/tcp_vegas.c
+++ b/net/ipv4/tcp_vegas.c
@@ -107,16 +107,16 @@ EXPORT_SYMBOL_GPL(tcp_vegas_init);
* o min-filter RTT samples from a much longer window (forever for now)
* to find the propagation delay (baseRTT)
*/
-void tcp_vegas_pkts_acked(struct sock *sk, u32 cnt, s32 rtt_us)
+void tcp_vegas_pkts_acked(struct sock *sk, const struct ack_sample *sample)
{
struct vegas *vegas = inet_csk_ca(sk);
u32 vrtt;
- if (rtt_us < 0)
+ if (sample->rtt_us < 0)
return;
/* Never allow zero rtt or baseRTT */
- vrtt = rtt_us + 1;
+ vrtt = sample->rtt_us + 1;
/* Filter to find propagation delay: */
if (vrtt < vegas->baseRTT)
diff --git a/net/ipv4/tcp_vegas.h b/net/ipv4/tcp_vegas.h
index ef9da53..248cfc0 100644
--- a/net/ipv4/tcp_vegas.h
+++ b/net/ipv4/tcp_vegas.h
@@ -17,7 +17,7 @@ struct vegas {
void tcp_vegas_init(struct sock *sk);
void tcp_vegas_state(struct sock *sk, u8 ca_state);
-void tcp_vegas_pkts_acked(struct sock *sk, u32 cnt, s32 rtt_us);
+void tcp_vegas_pkts_acked(struct sock *sk, const struct ack_sample *sample);
void tcp_vegas_cwnd_event(struct sock *sk, enum tcp_ca_event event);
size_t tcp_vegas_get_info(struct sock *sk, u32 ext, int *attr,
union tcp_cc_info *info);
diff --git a/net/ipv4/tcp_veno.c b/net/ipv4/tcp_veno.c
index 0d094b9..40171e1 100644
--- a/net/ipv4/tcp_veno.c
+++ b/net/ipv4/tcp_veno.c
@@ -69,16 +69,17 @@ static void tcp_veno_init(struct sock *sk)
}
/* Do rtt sampling needed for Veno. */
-static void tcp_veno_pkts_acked(struct sock *sk, u32 cnt, s32 rtt_us)
+static void tcp_veno_pkts_acked(struct sock *sk,
+ const struct ack_sample *sample)
{
struct veno *veno = inet_csk_ca(sk);
u32 vrtt;
- if (rtt_us < 0)
+ if (sample->rtt_us < 0)
return;
/* Never allow zero rtt or baseRTT */
- vrtt = rtt_us + 1;
+ vrtt = sample->rtt_us + 1;
/* Filter to find propagation delay: */
if (vrtt < veno->basertt)
diff --git a/net/ipv4/tcp_westwood.c b/net/ipv4/tcp_westwood.c
index c10732e..4b03a2e 100644
--- a/net/ipv4/tcp_westwood.c
+++ b/net/ipv4/tcp_westwood.c
@@ -99,12 +99,13 @@ static void westwood_filter(struct westwood *w, u32 delta)
* Called after processing group of packets.
* but all westwood needs is the last sample of srtt.
*/
-static void tcp_westwood_pkts_acked(struct sock *sk, u32 cnt, s32 rtt)
+static void tcp_westwood_pkts_acked(struct sock *sk,
+ const struct ack_sample *sample)
{
struct westwood *w = inet_csk_ca(sk);
- if (rtt > 0)
- w->rtt = usecs_to_jiffies(rtt);
+ if (sample->rtt_us > 0)
+ w->rtt = usecs_to_jiffies(sample->rtt_us);
}
/*
diff --git a/net/ipv4/tcp_yeah.c b/net/ipv4/tcp_yeah.c
index 3e6a472..028eb04 100644
--- a/net/ipv4/tcp_yeah.c
+++ b/net/ipv4/tcp_yeah.c
@@ -56,15 +56,16 @@ static void tcp_yeah_init(struct sock *sk)
tp->snd_cwnd_clamp = min_t(u32, tp->snd_cwnd_clamp, 0xffffffff/128);
}
-static void tcp_yeah_pkts_acked(struct sock *sk, u32 pkts_acked, s32 rtt_us)
+static void tcp_yeah_pkts_acked(struct sock *sk,
+ const struct ack_sample *sample)
{
const struct inet_connection_sock *icsk = inet_csk(sk);
struct yeah *yeah = inet_csk_ca(sk);
if (icsk->icsk_ca_state == TCP_CA_Open)
- yeah->pkts_acked = pkts_acked;
+ yeah->pkts_acked = sample->pkts_acked;
- tcp_vegas_pkts_acked(sk, pkts_acked, rtt_us);
+ tcp_vegas_pkts_acked(sk, sample);
}
static void tcp_yeah_cong_avoid(struct sock *sk, u32 ack, u32 acked)
--
2.8.0.rc2
^ permalink raw reply related
* [PATCH net-next] tcp: refactor struct tcp_skb_cb
From: Lawrence Brakmo @ 2016-05-07 3:35 UTC (permalink / raw)
To: netdev; +Cc: Kernel Team, Neal Cardwell, Eric Dumazet, Yuchung Cheng
Refactor tcp_skb_cb to create two overlaping areas to store
state for incoming or outgoing skbs based on comments by
Neal Cardwell to tcp_nv patch:
AFAICT this patch would not require an increase in the size of
sk_buff cb[] if it were to take advantage of the fact that the
tcp_skb_cb header.h4 and header.h6 fields are only used in the packet
reception code path, and this in_flight field is only used on the
transmit side.
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
---
include/net/tcp.h | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index dc588c3..c9ab561 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -765,11 +765,16 @@ struct tcp_skb_cb {
unused:6;
__u32 ack_seq; /* Sequence number ACK'd */
union {
- struct inet_skb_parm h4;
+ struct {
+ /* There is space for up to 20 bytes */
+ } tx; /* only used for outgoing skbs */
+ union {
+ struct inet_skb_parm h4;
#if IS_ENABLED(CONFIG_IPV6)
- struct inet6_skb_parm h6;
+ struct inet6_skb_parm h6;
#endif
- } header; /* For incoming frames */
+ } header; /* For incoming skbs */
+ };
};
#define TCP_SKB_CB(__skb) ((struct tcp_skb_cb *)&((__skb)->cb[0]))
--
2.8.0.rc2
^ permalink raw reply related
* Re: [PATCH RFC 1/5] net: phy: sun8i-h3-ephy: Add bindings for Allwinner H3 Ethernet PHY
From: Chen-Yu Tsai @ 2016-05-07 5:30 UTC (permalink / raw)
To: Hans De Goede, Maxime Ripard
Cc: Florian Fainelli, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, netdev, linux-arm-kernel, linux-kernel,
devicetree, LABBE Corentin, Andrew Lunn, Chen-Yu Tsai
In-Reply-To: <CAGb2v662vHfYox2Ff9Mm=sXq4UHg92SQe2ihnKY9Aa4X9yss4Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
On Tue, Apr 12, 2016 at 9:38 AM, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> On Tue, Apr 12, 2016 at 3:23 AM, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 04/04/16 09:22, Chen-Yu Tsai wrote:
>>> The Allwinner H3 SoC incorporates an Ethernet PHY. This is enabled and
>>> configured through a memory mapped hardware register.
>>>
>>> This same register also configures the MAC interface mode and TX clock
>>> source. Also covered by the register, but not supported in these bindings,
>>> are TX/RX clock delay chains and inverters, and an RMII module.
>>>
>>> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
>>> ---
>>> .../bindings/net/allwinner,sun8i-h3-ephy.txt | 44 ++++++++++++++++++++++
>>> 1 file changed, 44 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/net/allwinner,sun8i-h3-ephy.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-h3-ephy.txt b/Documentation/devicetree/bindings/net/allwinner,sun8i-h3-ephy.txt
>>> new file mode 100644
>>> index 000000000000..146f227e6d88
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-h3-ephy.txt
>>> @@ -0,0 +1,44 @@
>>> +* Allwinner H3 E(thernet) PHY
>>> +
>>> +The Allwinner H3 integrates an MII ethernet PHY. As with external PHYs,
>>> +before it can be configured over the MDIO bus and used, certain hardware
>>> +features must be configured, such as the PHY address and LED polarity.
>>
>> Is the internal PHY address really configurable? Not that there is
>> anything wrong with it, this is good.
>
> It is. Things that are configured or provided to a discrete PHY are routed
> to registers in the SoC, things such as PHY address, clocks, resets.
>
>>> +The PHY must also be powered on and brought out of reset.
>>> +
>>> +This is accomplished with regulators and pull-up/downs for external PHYs.
>>> +For this internal PHY, a hardware register is programmed.
>>> +
>>> +The same hardware register also contains clock and interface controls
>>> +for the MAC. This is also present in earlier SoCs, and is covered by
>>> +"allwinner,sun7i-a20-gmac-clk". The controls in the H3 are slightly
>>> +different due to the inclusion of what appears to be an RMII-MII
>>> +bridge.
>>> +
>>> +Required properties:
>>> +- compatible: should be "allwinner,sun8i-h3-ephy"
>>> +- reg: address and length of the register set for the device
>>> +- clocks: A phandle to the reference clock for this device
>>> +- resets: A phandle to the reset control for this device
>>> +
>>> +Ethernet PHY related properties:
>>> +- allwinner,ephy-addr: the MDIO bus address the PHY should respond to.
>>> + If this is not set, the external PHY is used, and
>>> + everything else in this section is ignored.
>>
>> So we are going to put the same value here, and in the actual Ethernet
>> PHY device tree node that should be hanging off the EMAC/MDIO bus
>> controller, this is confusing and error prone.
>
> Yes, that would be an issue when writing the DTS.
>>
>>> +- allwinner,leds-active-low: LEDs are active low. Without this, LEDs are
>>> + active high.
>>> +
>>> +Ethernet MAC clock related properties:
>>> +- #clock-cells: should be 0
>>> +- clock-output-names: "mac_tx"
>>> +
>>> +Example:
>>> +
>>> +ethernet-phy@01c00030 {
>>> + compatible = "allwinner,sun8i-h3-ephy";
>>> + reg = <0x01c00030 0x4>;
>>
>> Looking at this register space this looks more like an internal PHY SHIM
>> that is needed to be configured before the internal PHY can be access,
>> not a proper Ethernet PHY per-se, see replies in aptch 2.
>>
>> Should not this block be a second cell associated with the Ethernet MAC
>> block? One or the other are not going to be very useful without
>> knowledge of each other.
>
> True. However the lower half of the same register also controls the
> MAC interface mode and TX clock source and delays. This we had a clock
> driver that was used in conjuction with stmmac on earlier SoCs. I was
> hoping to keep that model with the newer EMAC. At the time it was
> argued that what seemed like a clock should be handled by a clock
> driver, instead of just a "syscon". If this is reaching too far to
> handle this new use case, I will happily just provide patches to merge
> this into the MAC.
Maxime, Hans, any thoughts?
It seems like it'd be easier to just fold this into the EMAC driver.
The register is not part of the clock controller in these new SoCs,
so it's nicer than what we had in A20/A31. It's also not just a clock
control, but a bunch of various controls.
ChenYu
> I would like to know how to deal with things like a PHY requiring
> some sort of shim driver, be it an internal one, or an external mfd
> chip that happens to have an Ethernet PHY included? How do we tie
> this into the PHY node under the MDIO bus?
--
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] macvtap: segmented packet is consumed
From: Shmulik Ladkani @ 2016-05-07 7:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Vlad Yasevich
In-Reply-To: <1462539501.13075.29.camel@edumazet-glaptop3.roam.corp.google.com>
Hi,
On Fri, 06 May 2016 05:58:21 -0700 Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> If GSO packet is segmented and its segments are properly queued,
> we call consume_skb() instead of kfree_skb() to be drop monitor
> friendly.
>
> Fixes: 3e4f8b7873709 ("macvtap: Perform GSO on forwarding path.")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Vlad Yasevich <vyasevic@redhat.com>
Reviewed-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
^ permalink raw reply
* Re: [PATCH RFC 1/5] net: phy: sun8i-h3-ephy: Add bindings for Allwinner H3 Ethernet PHY
From: Hans de Goede @ 2016-05-07 8:14 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard
Cc: Florian Fainelli, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, netdev, linux-arm-kernel, linux-kernel,
devicetree, LABBE Corentin, Andrew Lunn
In-Reply-To: <CAGb2v65qPMieWU-1CRJYL_zZ3JpUm83+AN477jGdrWYnjjJ66g@mail.gmail.com>
Hi,
On 07-05-16 07:30, Chen-Yu Tsai wrote:
> Hi,
>
> On Tue, Apr 12, 2016 at 9:38 AM, Chen-Yu Tsai <wens@csie.org> wrote:
>> On Tue, Apr 12, 2016 at 3:23 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>> On 04/04/16 09:22, Chen-Yu Tsai wrote:
>>>> The Allwinner H3 SoC incorporates an Ethernet PHY. This is enabled and
>>>> configured through a memory mapped hardware register.
>>>>
>>>> This same register also configures the MAC interface mode and TX clock
>>>> source. Also covered by the register, but not supported in these bindings,
>>>> are TX/RX clock delay chains and inverters, and an RMII module.
>>>>
>>>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>>>> ---
>>>> .../bindings/net/allwinner,sun8i-h3-ephy.txt | 44 ++++++++++++++++++++++
>>>> 1 file changed, 44 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/net/allwinner,sun8i-h3-ephy.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-h3-ephy.txt b/Documentation/devicetree/bindings/net/allwinner,sun8i-h3-ephy.txt
>>>> new file mode 100644
>>>> index 000000000000..146f227e6d88
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-h3-ephy.txt
>>>> @@ -0,0 +1,44 @@
>>>> +* Allwinner H3 E(thernet) PHY
>>>> +
>>>> +The Allwinner H3 integrates an MII ethernet PHY. As with external PHYs,
>>>> +before it can be configured over the MDIO bus and used, certain hardware
>>>> +features must be configured, such as the PHY address and LED polarity.
>>>
>>> Is the internal PHY address really configurable? Not that there is
>>> anything wrong with it, this is good.
>>
>> It is. Things that are configured or provided to a discrete PHY are routed
>> to registers in the SoC, things such as PHY address, clocks, resets.
>>
>>>> +The PHY must also be powered on and brought out of reset.
>>>> +
>>>> +This is accomplished with regulators and pull-up/downs for external PHYs.
>>>> +For this internal PHY, a hardware register is programmed.
>>>> +
>>>> +The same hardware register also contains clock and interface controls
>>>> +for the MAC. This is also present in earlier SoCs, and is covered by
>>>> +"allwinner,sun7i-a20-gmac-clk". The controls in the H3 are slightly
>>>> +different due to the inclusion of what appears to be an RMII-MII
>>>> +bridge.
>>>> +
>>>> +Required properties:
>>>> +- compatible: should be "allwinner,sun8i-h3-ephy"
>>>> +- reg: address and length of the register set for the device
>>>> +- clocks: A phandle to the reference clock for this device
>>>> +- resets: A phandle to the reset control for this device
>>>> +
>>>> +Ethernet PHY related properties:
>>>> +- allwinner,ephy-addr: the MDIO bus address the PHY should respond to.
>>>> + If this is not set, the external PHY is used, and
>>>> + everything else in this section is ignored.
>>>
>>> So we are going to put the same value here, and in the actual Ethernet
>>> PHY device tree node that should be hanging off the EMAC/MDIO bus
>>> controller, this is confusing and error prone.
>>
>> Yes, that would be an issue when writing the DTS.
>>>
>>>> +- allwinner,leds-active-low: LEDs are active low. Without this, LEDs are
>>>> + active high.
>>>> +
>>>> +Ethernet MAC clock related properties:
>>>> +- #clock-cells: should be 0
>>>> +- clock-output-names: "mac_tx"
>>>> +
>>>> +Example:
>>>> +
>>>> +ethernet-phy@01c00030 {
>>>> + compatible = "allwinner,sun8i-h3-ephy";
>>>> + reg = <0x01c00030 0x4>;
>>>
>>> Looking at this register space this looks more like an internal PHY SHIM
>>> that is needed to be configured before the internal PHY can be access,
>>> not a proper Ethernet PHY per-se, see replies in aptch 2.
>>>
>>> Should not this block be a second cell associated with the Ethernet MAC
>>> block? One or the other are not going to be very useful without
>>> knowledge of each other.
>>
>> True. However the lower half of the same register also controls the
>> MAC interface mode and TX clock source and delays. This we had a clock
>> driver that was used in conjuction with stmmac on earlier SoCs. I was
>> hoping to keep that model with the newer EMAC. At the time it was
>> argued that what seemed like a clock should be handled by a clock
>> driver, instead of just a "syscon". If this is reaching too far to
>> handle this new use case, I will happily just provide patches to merge
>> this into the MAC.
>
> Maxime, Hans, any thoughts?
>
> It seems like it'd be easier to just fold this into the EMAC driver.
> The register is not part of the clock controller in these new SoCs,
> so it's nicer than what we had in A20/A31. It's also not just a clock
> control, but a bunch of various controls.
I don't know the emac stuff well enough to really have an opinion,
but with that said I've no objections against just folding this into
the driver. If you believe that is best, go for it.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] net: l3mdev: Add hook in ip and ipv6
From: Shmulik Ladkani @ 2016-05-07 8:30 UTC (permalink / raw)
To: David Ahern; +Cc: netdev
In-Reply-To: <1462585781-9146-2-git-send-email-dsa@cumulusnetworks.com>
Hi David,
On Fri, 6 May 2016 18:49:40 -0700 David Ahern <dsa@cumulusnetworks.com> wrote:
> +static bool ipv6_ndisc_frame(const struct sk_buff *skb)
> +{
> + const struct ipv6hdr *ipv6h = (struct ipv6hdr *)skb->data;
> + size_t hlen = sizeof(*ipv6h);
> + bool rc = false;
> +
> + if (ipv6h->nexthdr == NEXTHDR_ICMP) {
> + const struct icmp6hdr *icmph;
> +
> + if (skb->len < hlen + sizeof(*icmph))
> + goto out;
> +
> + icmph = (struct icmp6hdr *)(skb->data + sizeof(*ipv6h));
> + switch (icmph->icmp6_type) {
Don't we need an additional pskb_may_pull here?
If I get it right, 'ipv6_rcv' only assures sizeof(ipv6hdr) to be in the
linear header (unless it's a NEXTHDR_HOP, which is not the case here).
> +static inline
> +struct sk_buff *l3mdev_l3_rcv(struct sk_buff *skb, u16 proto)
> +{
> + struct net_device *master = NULL;
> +
> + if (netif_is_l3_slave(skb->dev))
> + master = netdev_master_upper_dev_get_rcu(skb->dev);
> +
> + else if (netif_is_l3_master(skb->dev))
> + master = skb->dev;
> +
> + if (master && master->l3mdev_ops->l3mdev_l3_rcv)
> + skb = master->l3mdev_ops->l3mdev_l3_rcv(master, skb, proto);
In the case where netif_is_l3_master(skb->dev) is true, can you explain
why we need to pass it through the l3mdev_l3_rcv callback again?
Regards,
Shmulik
^ permalink raw reply
* Re: rtk8168 driver help needed
From: Francois Romieu @ 2016-05-07 8:35 UTC (permalink / raw)
To: Murali Karicheri; +Cc: open list:TI NETCP ETHERNET DRIVER
In-Reply-To: <572D147C.8020203@ti.com>
Murali Karicheri <m-karicheri2@ti.com> :
[...]
> I am trying to integrate the rtl8168 PCIe card to have Ethernet functional
> on my Keystone EVM.
Which (EVM) one ?
> I purchased the rtl8111c Gib card from Amazon. The Card is detected
> by the RC and I can see it is enumerated and show up when doing lspci command.
What does "the RC" mean ? A different PC ?
> However I can't get the Ethernet port functional.
> Does this need MSI interrupt ?
No.
> I can't see it has requested any.
Yes, something went really, really wrong. See below.
[...]
> [ 2.303965] PCI host bridge /soc/pcie@21800000 ranges:
> [ 2.309108] No bus range found for /soc/pcie@21800000, using [bus 00-ff]
> [ 2.316269] IO 0x23250000..0x23253fff -> 0x00000000
> [ 2.321499] MEM 0x50000000..0x5fffffff -> 0x50000000
> [ 2.331666] keystone-pcie 21801000.pcie: PCI host bridge to bus 0000:00
> [ 2.338283] pci_bus 0000:00: root bus resource [bus 00-ff]
> [ 2.343937] pci_bus 0000:00: root bus resource [io 0x0000-0x3fff]
> [ 2.350114] pci_bus 0000:00: root bus resource [mem 0x50000000-0x5fffffff]
> [ 2.357095] pci 0000:00:00.0: [104c:b00b] type 01 class 0x060400
> [ 2.357665] PCI: bus0: Fast back to back transfers disabled
> [ 2.363717] pci 0000:01:00.0: [10ec:8168] type 00 class 0x020000
> [ 2.363809] pci 0000:01:00.0: reg 0x10: [io 0x0000-0x00ff]
> [ 2.363867] pci 0000:01:00.0: reg 0x18: [mem 0x00000000-0x00000fff 64bit]
> [ 2.363909] pci 0000:01:00.0: reg 0x20: [mem 0x00000000-0x0000ffff 64bit pref]
> [ 2.363939] pci 0000:01:00.0: reg 0x30: [mem 0x00000000-0x0001ffff pref]
> [ 2.364099] pci 0000:01:00.0: supports D1 D2
> [ 2.364116] pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> [ 2.381251] PCI: bus1: Fast back to back transfers disabled
> [ 2.386989] pci 0000:00:00.0: BAR 8: assigned [mem 0x50000000-0x500fffff]
> [ 2.393937] pci 0000:00:00.0: BAR 9: assigned [mem 0x50100000-0x501fffff pref]
> [ 2.401221] pci 0000:00:00.0: BAR 7: assigned [io 0x1000-0x1fff]
> [ 2.407320] pci 0000:01:00.0: BAR 6: assigned [mem 0x50100000-0x5011ffff pref]
> [ 2.414597] pci 0000:01:00.0: BAR 4: assigned [mem 0x50120000-0x5012ffff 64bit pref]
> [ 2.422380] pci 0000:01:00.0: BAR 2: assigned [mem 0x50000000-0x50000fff 64bit]
> [ 2.429702] pci 0000:01:00.0: BAR 0: assigned [io 0x1000-0x10ff]
> [ 2.435821] pci 0000:00:00.0: PCI bridge to [bus 01]
> [ 2.440783] pci 0000:00:00.0: bridge window [io 0x1000-0x1fff]
> [ 2.446896] pci 0000:00:00.0: bridge window [mem 0x50000000-0x500fffff]
> [ 2.453699] pci 0000:00:00.0: bridge window [mem 0x50100000-0x501fffff pref]
> [ 2.461453] pcieport 0000:00:00.0: Signaling PME through PCIe PME interrupt
> [ 2.468411] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
> [ 2.475075] pcie_pme 0000:00:00.0:pcie01: service driver pcie_pme loaded
> [ 2.475392] aer 0000:00:00.0:pcie02: service driver aer loaded
> [ 2.475652] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> [ 2.481419] r8169 0000:01:00.0: enabling device (0140 -> 0143)
> [ 2.488865] r8169 0000:01:00.0 eth0: RTL8169 at 0xf0d6a000, 00:00:00:00:00:00, XID 00000000 IRQ 286
No need to go further, there is a serious problem here.
Most of the XID bits are read from a mapped register. They're definitely not
expected to be null as the driver requires it to identify a proper chipset
(the common PCI configuration registers only tell that you aren't dealing
with a coffee machine).
Any read returning zeroes would not surprize me.
[...]
> Can someone help me figure out what is missing ?
Hardly at this point. I can only suggest to switch power off, plug
the 8168 device in a x86 (32 or 64 bits) system and check how it behaves.
--
Ueimor
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: original ingress device index in PKTINFO
From: Shmulik Ladkani @ 2016-05-07 8:41 UTC (permalink / raw)
To: David Ahern; +Cc: netdev
In-Reply-To: <1462585781-9146-3-git-send-email-dsa@cumulusnetworks.com>
Hi David,
On Fri, 6 May 2016 18:49:41 -0700 David Ahern <dsa@cumulusnetworks.com> wrote:
> Applications such as OSPF and BFD need the original ingress device not
> the VRF device;
Would you consider this true for any IP_PKTINFO users in VRF setups?
> @@ -1193,7 +1193,12 @@ void ipv4_pktinfo_prepare(const struct sock *sk, struct sk_buff *skb)
> ipv6_sk_rxinfo(sk);
>
> if (prepare && skb_rtable(skb)) {
> - pktinfo->ipi_ifindex = inet_iif(skb);
> + /* skb->cb is overloaded: prior to this point it is IP{6}CB
> + * which has interface index (iif) as the first member of the
> + * underlying inet{6}_skb_parm struct. This code then overlays
> + * PKTINFO_SKB_CB and in_pktinfo also has iif as the first
> + * element so the iif is picked up from the prior IPCB
> + */
Better if there was a guarantee in the code that inet_skb_parm layout stays
that way. Or instead just explicitly assign the iif.
Regards,
Shmulik
^ permalink raw reply
* Re: [PATCH net] netfilter: nf_conntrack: Use net_mutex for helper unregistration.
From: Florian Westphal @ 2016-05-07 9:18 UTC (permalink / raw)
To: Joe Stringer; +Cc: Pablo Neira Ayuso, netdev, netfilter-devel, Florian Westphal
In-Reply-To: <CAPWQB7H0qdi2+rL92_O=-ku+FeqDSGEmn+d0wivk-1RSAsgeFw@mail.gmail.com>
Joe Stringer <joe@ovn.org> wrote:
> > If so, probably I can append this as comment to this function so we
> > don't forget. If we ever have .exit callbacks (I don't expect so), we
> > would need to wait for worker completion.
>
> Sounds reasonable to me.
>
> I see there's a bunch of other unregister locations like
> nf_nat_l3proto_clean(), nf_nat_l4proto_clean(), nf_unregister_hook()
> which might need similar treatment?
I think they are fine, hook entries are duplicated per netns so we
should not access data in a removed module.
However, we might be able to trigger the
WARN(1, "nf_unregister_net_hook: hook not found!\n");
part in nf_unregister_net_hook():
[ destroy netns -> destruction queued -> rmmod -> all hooks are
destroyed -> netns workq runs -> nf_unregister_net_hook gets called
-> hook already gone ]
For nf_nat_l3|4proto_clean I don't see a problem either, if netns
is gone all these conntracks will be zapped once the workqueue runs, even if
the iteration in those function did not see the netns anymore.
Cheers,
Florian
^ permalink raw reply
* Re: A couple of questions about the SKB fragments
From: Ilya Matveychikov @ 2016-05-07 9:21 UTC (permalink / raw)
To: Edward Cree; +Cc: netdev, Aleksey.Baulin
In-Reply-To: <572B2AEE.1020802@solarflare.com>
2016-05-05 14:13 GMT+03:00 Edward Cree <ecree@solarflare.com>:
> On 05/05/16 08:40, Ilya Matveychikov wrote:
> > Is there any docs except the kernel sources itself to refer to?
> davem has some docs up at http://vger.kernel.org/~davem/skb.html and
> http://vger.kernel.org/~davem/skb_data.html
> In particular note the following:
> "The frag_list is used to maintain a chain of SKBs organized for
> fragmentation purposes, it is _not_ used for maintaining paged data."
> So my reading would suggest there is no way to multiple-layer-fragment
> an SKB; the frags are page pointers and offsets, not entire sk_buff
> structs in their own right.
>
Seems that the docs is slightly outdated. I think the structure of SKB does
not impose any restrictions on the nesting of the fragments. But is there
any of them in the kernel's code?
^ permalink raw reply
* Re: OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)
From: Kevin Darbyshire-Bryant @ 2016-05-07 9:57 UTC (permalink / raw)
To: Jesper Dangaard Brouer, Eric Dumazet, Felix Fietkau, Dave Taht
Cc: make-wifi-fast, zajec5, ath10k, codel@lists.bufferbloat.net,
netdev@vger.kernel.org, Jonathan Morton, Roman Yeryomin
In-Reply-To: <20160506114243.4eb4f95e@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 1814 bytes --]
On 06/05/16 10:42, Jesper Dangaard Brouer wrote:
> Hi Felix,
>
> This is an important fix for OpenWRT, please read!
>
> OpenWRT changed the default fq_codel sch->limit from 10240 to 1024,
> without also adjusting q->flows_cnt. Eric explains below that you must
> also adjust the buckets (q->flows_cnt) for this not to break. (Just
> adjust it to 128)
>
> Problematic OpenWRT commit in question:
> http://git.openwrt.org/?p=openwrt.git;a=patch;h=12cd6578084e
> 12cd6578084e ("kernel: revert fq_codel quantum override to prevent it from causing too much cpu load with higher speed (#21326)")
I 'pull requested' this to the lede-staging tree on github.
https://github.com/lede-project/staging/pull/11
One way or another Felix & co should see the change :-)
>
>
> I also highly recommend you cherry-pick this very recent commit:
> net-next: 9d18562a2278 ("fq_codel: add batch ability to fq_codel_drop()")
> https://git.kernel.org/davem/net-next/c/9d18562a227
>
> This should fix very high CPU usage in-case fq_codel goes into drop mode.
> The problem is that drop mode was considered rare, and implementation
> wise it was chosen to be more expensive (to save cycles on normal mode).
> Unfortunately is it easy to trigger with an UDP flood. Drop mode is
> especially expensive for smaller devices, as it scans a 4K big array,
> thus 64 cache misses for small devices!
>
> The fix is to allow drop-mode to bulk-drop more packets when entering
> drop-mode (default 64 bulk drop). That way we don't suddenly
> experience a significantly higher processing cost per packet, but
> instead can amortize this.
I haven't done the above cherry-pick patch & backport patch creation for
4.4/4.1/3.18 yet - maybe if $dayjob permits time and no one else beats
me to it :-)
Kevin
[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]
[-- Attachment #2: Type: text/plain, Size: 146 bytes --]
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* Re: [PATCH net v3] vlan: Propagate MAC address to VLANs
From: Mike Manning @ 2016-05-07 9:58 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Netdev
In-Reply-To: <CAKgT0Uerb6k2aDhzJ9y+O7E5O40orX7pwOb2K2JEu048UfbFag@mail.gmail.com>
On 05/06/2016 08:48 PM, Alexander Duyck wrote:
> On Fri, May 6, 2016 at 12:36 PM, Mike Manning <mmanning@brocade.com> wrote:
>> On 05/06/2016 06:02 PM, Alexander Duyck wrote:
>>> On Fri, May 6, 2016 at 6:26 AM, Mike Manning <mmanning@brocade.com> wrote:
>>>> The MAC address of the physical interface is only copied to the VLAN
>>>> when it is first created, resulting in an inconsistency after MAC
>>>> address changes of only newly created VLANs having an up-to-date MAC.
>>>>
>>>> The VLANs should continue inheriting the MAC address of the physical
>>>> interface, unless explicitly changed to be different from this.
>>>> This allows IPv6 EUI64 addresses for the VLAN to reflect any changes
>>>> to the MAC of the physical interface and thus for DAD to behave as
>>>> expected.
>>>>
>>>> Signed-off-by: Mike Manning <mmanning@brocade.com>
>>>> ---
>>>> include/linux/if_vlan.h | 2 ++
>>>> net/8021q/vlan.c | 17 +++++++++++------
>>>> net/8021q/vlan_dev.c | 13 ++++++++++---
>>>> 3 files changed, 23 insertions(+), 9 deletions(-)
>>>>
>>>> --- a/include/linux/if_vlan.h
>>>> +++ b/include/linux/if_vlan.h
>>>> @@ -138,6 +138,7 @@ struct netpoll;
>>>> * @flags: device flags
>>>> * @real_dev: underlying netdevice
>>>> * @real_dev_addr: address of underlying netdevice
>>>> + * @addr_assign_type: address assignment type
>>>> * @dent: proc dir entry
>>>> * @vlan_pcpu_stats: ptr to percpu rx stats
>>>> */
>>>> @@ -153,6 +154,7 @@ struct vlan_dev_priv {
>>>>
>>>> struct net_device *real_dev;
>>>> unsigned char real_dev_addr[ETH_ALEN];
>>>> + unsigned char addr_assign_type;
>>>>
>>>> struct proc_dir_entry *dent;
>>>> struct vlan_pcpu_stats __percpu *vlan_pcpu_stats;
>>>
>>> Please don't start adding new members to structures when it already
>>> exists in the net_device. If anything you should be able to drop
>>> read_dev_addr if you do this correctly because you shouldn't need to
>>> clone the lower dev address to watch for changes. All you will need
>>> to do is watch NET_ADDR_STOLEN.
>>>
>>
>> Thanks for the detailed review. I had initially used the existing type
>> in net_device, but the problem with this was that it got overwritten to
>> NET_ADDR_SET in dev_set_mac_address(), which I was reluctant to modify.
>> It would just be a case of setting the type earlier in that function
>> (and caching the previous value in case there is an error).
>>
>> However, based on your later comment, it seems I should not bother with
>> the approach I have here, namely that if the VLAN MAC is set to the same
>> value as that of the lower device MAC, that is to be considered as
>> resetting it and thus for MAC inheritance to resume. Instead, I will just
>> make this a 1-shot transition, i.e. the VLAN MAC starts off as inherited,
>> and if it is set to anything (even the value of the lower device MAC),
>> inheritance is stopped. I agree this makes for a far simpler changeset.
>>
>> I don't think I can remove real_dev_addr, as that is still needed for
>> the existing functionality in vlan_sync_address() to determine if the sync
>> should be done, also as a way of caching it for handling in vlan_dev_open().
>
> The thing is that logic isn't really needed anymore though if you are
> going to be following the lower dev. If you follow the code what it
> is doing is adding the address via dev_uc_add if the lower address
> moves away from the VLAN address. With your changes you are updating
> the VLAN MAC address to the lower value in the NET_ADDR_STOLEN case so
> you don't need to add or remove an extra unicast address. If the user
> sets the MAC address you can then use the vlandev->dev_addr as the
> address you add/remove from the unicast list and you probably don't
> need to bother with tracking the lower device state anyway.
>
I agree that this logic is not needed at all for the NET_ADDR_STOLEN case.
However, once the VLAN MAC has been explicitly set, the situation reverts
to the existing functionality, whereby real_dev_addr is used to ensure that
dev_uc_add/del are not incorrectly called multiple times for the same MACs.
As an example, if the lower device MAC is different from the VLAN MAC and
is repeatedly set to the same value, then without this check on
real_dev_addr, the refcnt for the VLAN MAC would keep getting incremented.
The checks on the lower device MAC need to remain in place so as to call
dev_uc_add/del if this is changed to be different/same as the VLAN MAC.
For this reason, I have left this logic unchanged. Also, to ensure that
the value of real_dev_addr is correct on the transition to NET_ADDR_SET,
I keep this up-to-date (the alternative would be to add some code in
vlan_dev_set_mac_address() to copy dev_addr to real_dev_addr if the type on
entry is NET_ADDR_STOLEN).
>> As a matter of interest, what is the advantage of not updating the VLAN
>> MAC when it is down? I appreciate that one should not add/delete
>> secondary unicast addresses in this case, but there is no such
>> restriction for copying the MAC.
>
> Basically you are just wasting cycles messing with it while it is
> down. You don't need to bother with syncing up the addresses until
> you bring the interface up. At that point you essentially need to do
> the vlan_sync_address type work anyway because you have to push your
> address to the lower dev, or you have to pull it up from the lower dev
> in the case of the stolen address. You don't want to have MAC
> addresses written to the device for an interface that is down.
>
Thanks, I no longer copy the address in vlan_sync_address() when the interface
is down, and have moved this to vlan_dev_open() instead.
^ permalink raw reply
* [PATCH net v4] vlan: Propagate MAC address to VLANs
From: Mike Manning @ 2016-05-07 10:00 UTC (permalink / raw)
To: netdev
In-Reply-To: <572DB364.2040109@brocade.com>
The MAC address of the physical interface is only copied to the VLAN
when it is first created, resulting in an inconsistency after MAC
address changes of only newly created VLANs having an up-to-date MAC.
The VLANs should continue inheriting the MAC address of the physical
interface until the VLAN MAC address is explicitly set to any value.
This allows IPv6 EUI64 addresses for the VLAN to reflect any changes
to the MAC of the physical interface and thus for DAD to behave as
expected.
Signed-off-by: Mike Manning <mmanning@brocade.com>
---
net/8021q/vlan.c | 7 +++++++
net/8021q/vlan_dev.c | 14 ++++++++++----
2 files changed, 17 insertions(+), 4 deletions(-)
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -291,6 +291,12 @@ static void vlan_sync_address(struct net
if (ether_addr_equal(vlan->real_dev_addr, dev->dev_addr))
return;
+ /* vlan continues to inherit address of parent interface */
+ if (vlandev->addr_assign_type == NET_ADDR_STOLEN) {
+ ether_addr_copy(vlandev->dev_addr, dev->dev_addr);
+ goto out;
+ }
+
/* vlan address was different from the old address and is equal to
* the new address */
if (!ether_addr_equal(vlandev->dev_addr, vlan->real_dev_addr) &&
@@ -303,6 +309,7 @@ static void vlan_sync_address(struct net
!ether_addr_equal(vlandev->dev_addr, dev->dev_addr))
dev_uc_add(dev, vlandev->dev_addr);
+out:
ether_addr_copy(vlan->real_dev_addr, dev->dev_addr);
}
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -255,9 +255,13 @@ static int vlan_dev_open(struct net_devi
return -ENETDOWN;
if (!ether_addr_equal(dev->dev_addr, real_dev->dev_addr)) {
- err = dev_uc_add(real_dev, dev->dev_addr);
- if (err < 0)
- goto out;
+ if (dev->addr_assign_type == NET_ADDR_STOLEN) {
+ ether_addr_copy(dev->dev_addr, real_dev->dev_addr);
+ } else {
+ err = dev_uc_add(real_dev, dev->dev_addr);
+ if (err < 0)
+ goto out;
+ }
}
if (dev->flags & IFF_ALLMULTI) {
@@ -558,8 +562,10 @@ static int vlan_dev_init(struct net_devi
/* ipv6 shared card related stuff */
dev->dev_id = real_dev->dev_id;
- if (is_zero_ether_addr(dev->dev_addr))
+ if (is_zero_ether_addr(dev->dev_addr)) {
eth_hw_addr_inherit(dev, real_dev);
+ dev->addr_assign_type = NET_ADDR_STOLEN;
+ }
if (is_zero_ether_addr(dev->broadcast))
memcpy(dev->broadcast, real_dev->broadcast, dev->addr_len);
--
1.7.10.4
^ permalink raw reply
* STRICTLY CONFIDENTIAL.
From: Acct. Dept. Bank Of China @ 2016-05-07 9:42 UTC (permalink / raw)
I have important transaction for you as next of kin to claim US$8.37m email me at zhu.shumin@yahoo.com.hk so i can send you more details
Thanks
Mr.Zhu Shumin
(Security Code 00746igit)
= = = = = = = = = = = = =
Move to inbox
^ permalink raw reply
* RE: [PATCH v9 net-next 1/2] hv_sock: introduce Hyper-V Sockets
From: Dexuan Cui @ 2016-05-07 10:49 UTC (permalink / raw)
To: David Miller
Cc: gregkh@linuxfoundation.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
olaf@aepfle.de, apw@canonical.com, jasowang@redhat.com,
cavery@redhat.com, KY Srinivasan, Haiyang Zhang, joe@perches.com,
vkuznets@redhat.com
In-Reply-To: <20160506.130353.2082047339292515860.davem@davemloft.net>
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Saturday, May 7, 2016 1:04
> To: Dexuan Cui <decui@microsoft.com>
> Cc: gregkh@linuxfoundation.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; devel@linuxdriverproject.org; olaf@aepfle.de;
> apw@canonical.com; jasowang@redhat.com; cavery@redhat.com; KY
> Srinivasan <kys@microsoft.com>; Haiyang Zhang <haiyangz@microsoft.com>;
> joe@perches.com; vkuznets@redhat.com
> Subject: Re: [PATCH v9 net-next 1/2] hv_sock: introduce Hyper-V Sockets
>
> From: Dexuan Cui <decui@microsoft.com>
> Date: Wed, 4 May 2016 09:56:57 -0700
>
> > +#define VMBUS_RINGBUFFER_SIZE_HVSOCK_RECV (5 * PAGE_SIZE)
> > +#define VMBUS_RINGBUFFER_SIZE_HVSOCK_SEND (5 * PAGE_SIZE)
> > +
> > +#define HVSOCK_RCV_BUF_SZ
> VMBUS_RINGBUFFER_SIZE_HVSOCK_RECV
> ...
> > +struct hvsock_sock {
> ...
> > + /* The 'hdr' and 'buf' in the below 'send' and 'recv' definitions must
> > + * be consecutive: see hvsock_send_data() and hvsock_recv_data().
> > + */
> > + struct {
> > + struct vmpipe_proto_header hdr;
> > + u8 buf[HVSOCK_SND_BUF_SZ];
> > + } send;
> > +
> > + struct {
> > + struct vmpipe_proto_header hdr;
> > + u8 buf[HVSOCK_RCV_BUF_SZ];
> > +
> > + unsigned int data_len;
> > + unsigned int data_offset;
> > + } recv;
>
> I don't think allocating 5 pages of unswappable memory for every Hyper-V
> socket
> created is reasonable.
Thanks for the comment, David!
I should be able to make 'send', 'recv' here to pointers and use vmalloc()
to allocate the memory for them. I will do this.
Thanks,
-- Dexuan
^ permalink raw reply
* [PATCH v2 0/2] ravb: Add missing free_irq() calls to ravb_close()
From: Geert Uytterhoeven @ 2016-05-07 11:17 UTC (permalink / raw)
To: David S. Miller, Sergei Shtylyov
Cc: Yoshihiro Kaneko, Simon Horman, netdev, linux-renesas-soc,
Geert Uytterhoeven
Hi Dave,
When reopening the network device on ra7795/salvator-x, e.g. after a
DHCP timeout:
IP-Config: Reopening network devices...
genirq: Flags mismatch irq 139. 00000000 (eth0:ch24:emac) vs. 00000000 (
ravb e6800000.ethernet eth0: cannot request IRQ eth0:ch24:emac
IP-Config: Failed to open eth0
IP-Config: No network devices available
The "mismatch" is due to requesting an IRQ that is already in use,
while IRQF_PROBE_SHARED wasn't set.
However, the real cause is that ravb_close() doesn't release any of the
R-Car Gen3-specific secondary IRQs. Hence the following two patches add
the missing free_irq() calls to fix this.
As the code has been changed in net-next.git to support more interrupts,
and these weren't freed neither, I'm sending two patches:
1. The first patch applies to net.git,
2. The second patch applies to net-next.git.
If you prefer the second patch to be replaced by a version that applies
to net-next.git after you will have applied the first patch to net.git,
and merged net.git into net-next.git, just let me know.
Chances compared to the previous version:
- Add version against net.git,
- Clearly state which version the second patch is against,
- Add Fixes tags.
Thanks!
Geert Uytterhoeven (1):
ravb: Add missing free_irq() call to ravb_close()
ravb: Add missing free_irq() calls to ravb_close()
drivers/net/ethernet/renesas/ravb_main.c | 9 +++++++
1 files changed, 9 insertions(+)
--
1.9.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 1/2 -net] ravb: Add missing free_irq() call to ravb_close()
From: Geert Uytterhoeven @ 2016-05-07 11:17 UTC (permalink / raw)
To: David S. Miller, Sergei Shtylyov
Cc: Yoshihiro Kaneko, Simon Horman, netdev, linux-renesas-soc,
Geert Uytterhoeven
In-Reply-To: <1462619832-5177-1-git-send-email-geert+renesas@glider.be>
When reopening the network device on ra7795/salvator-x, e.g. after a
DHCP timeout:
IP-Config: Reopening network devices...
genirq: Flags mismatch irq 139. 00000000 (eth0:ch24:emac) vs. 00000000 (eth0:ch24:emac)
ravb e6800000.ethernet eth0: cannot request IRQ eth0:ch24:emac
IP-Config: Failed to open eth0
IP-Config: No network devices available
The "mismatch" is due to requesting an IRQ that is already in use,
while IRQF_PROBE_SHARED wasn't set.
However, the real cause is that ravb_close() doesn't release the R-Car
Gen3-specific secondary IRQ.
Add the missing free_irq() call to fix this.
Fixes: 22d4df8ff3a3cc72 ("ravb: Add support for r8a7795 SoC")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
This version is against net.git.
v2:
- New.
---
drivers/net/ethernet/renesas/ravb_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 9e2a0bd8f5a88803..4277d0c12101fef7 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -1506,6 +1506,8 @@ static int ravb_close(struct net_device *ndev)
priv->phydev = NULL;
}
+ if (priv->chip_id == RCAR_GEN3)
+ free_irq(priv->emac_irq, ndev);
free_irq(ndev->irq, ndev);
napi_disable(&priv->napi[RAVB_NC]);
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/2 -net-next] ravb: Add missing free_irq() calls to ravb_close()
From: Geert Uytterhoeven @ 2016-05-07 11:17 UTC (permalink / raw)
To: David S. Miller, Sergei Shtylyov
Cc: Yoshihiro Kaneko, Simon Horman, netdev, linux-renesas-soc,
Geert Uytterhoeven
In-Reply-To: <1462619832-5177-1-git-send-email-geert+renesas@glider.be>
When reopening the network device on ra7795/salvator-x, e.g. after a
DHCP timeout:
IP-Config: Reopening network devices...
genirq: Flags mismatch irq 139. 00000000 (eth0:ch24:emac) vs. 00000000 (
ravb e6800000.ethernet eth0: cannot request IRQ eth0:ch24:emac
IP-Config: Failed to open eth0
IP-Config: No network devices available
The "mismatch" is due to requesting an IRQ that is already in use,
while IRQF_PROBE_SHARED wasn't set.
However, the real cause is that ravb_close() doesn't release any of the
R-Car Gen3-specific secondary IRQs.
Add the missing free_irq() calls to fix this.
Fixes: 22d4df8ff3a3cc72 ("ravb: Add support for r8a7795 SoC")
Fixes: f51bdc236b6c5835 ("ravb: Add dma queue interrupt support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
This version is against net-next.git.
v2:
- Clearly state which version this patch is against,
- Add Fixes tags.
---
drivers/net/ethernet/renesas/ravb_main.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 34066e0649f5c673..867caf6e7a5a65ad 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -1667,6 +1667,13 @@ static int ravb_close(struct net_device *ndev)
priv->phydev = NULL;
}
+ if (priv->chip_id != RCAR_GEN2) {
+ free_irq(priv->tx_irqs[RAVB_NC], ndev);
+ free_irq(priv->rx_irqs[RAVB_NC], ndev);
+ free_irq(priv->tx_irqs[RAVB_BE], ndev);
+ free_irq(priv->rx_irqs[RAVB_BE], ndev);
+ free_irq(priv->emac_irq, ndev);
+ }
free_irq(ndev->irq, ndev);
napi_disable(&priv->napi[RAVB_NC]);
--
1.9.1
^ permalink raw reply related
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