* Re: [PATCH net-next 30/35] qlge: Use pci_enable_msix_range() instead of pci_enable_msix()
From: Jitendra Kalsaria @ 2014-02-18 19:20 UTC (permalink / raw)
To: Alexander Gordeev, linux-kernel
Cc: Shahed Shaikh, Ron Mercer, Dept-Eng Linux Driver, netdev,
linux-pci
In-Reply-To: <443a0172bc2fe0aa92fca6044d7374475e2ad4c1.1392717503.git.agordeev@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 812 bytes --]
On 2/18/14 2:11 AM, "Alexander Gordeev" <agordeev@redhat.com> wrote:
>As result of deprecation of MSI-X/MSI enablement functions
>pci_enable_msix() and pci_enable_msi_block() all drivers
>using these two interfaces need to be updated to use the
>new pci_enable_msi_range() and pci_enable_msix_range()
>interfaces.
>
>Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
>Cc: Shahed Shaikh <shahed.shaikh@qlogic.com>
>Cc: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
>Cc: Ron Mercer <ron.mercer@qlogic.com>
>Cc: linux-driver@qlogic.com
>Cc: netdev@vger.kernel.org
>Cc: linux-pci@vger.kernel.org
>---
> drivers/net/ethernet/qlogic/qlge/qlge_main.c | 15 ++++-----------
> 1 files changed, 4 insertions(+), 11 deletions(-)
Acked-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 4634 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 29/35] qlge: Get rid of an redundant assignment
From: Jitendra Kalsaria @ 2014-02-18 19:19 UTC (permalink / raw)
To: Alexander Gordeev, linux-kernel
Cc: Shahed Shaikh, Ron Mercer, Dept-Eng Linux Driver, netdev,
linux-pci
In-Reply-To: <bffe424063b212553530f64b3282e260e2a37074.1392717503.git.agordeev@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]
On 2/18/14 2:11 AM, "Alexander Gordeev" <agordeev@redhat.com> wrote:
>Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
>Cc: Shahed Shaikh <shahed.shaikh@qlogic.com>
>Cc: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
>Cc: Ron Mercer <ron.mercer@qlogic.com>
>Cc: linux-driver@qlogic.com
>Cc: netdev@vger.kernel.org
>Cc: linux-pci@vger.kernel.org
>---
> drivers/net/ethernet/qlogic/qlge/qlge_main.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
Acked-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
>
>diff --git a/drivers/net/ethernet/qlogic/qlge/qlge_main.c
>b/drivers/net/ethernet/qlogic/qlge/qlge_main.c
>index ce2cfdd..82bace5 100644
>--- a/drivers/net/ethernet/qlogic/qlge/qlge_main.c
>+++ b/drivers/net/ethernet/qlogic/qlge/qlge_main.c
>@@ -3346,7 +3346,6 @@ static void ql_enable_msix(struct ql_adapter *qdev)
> qdev->msi_x_entry = NULL;
> netif_warn(qdev, ifup, qdev->ndev,
> "MSI-X Enable failed, trying MSI.\n");
>- qdev->intr_count = 1;
> qlge_irq_type = MSI_IRQ;
> } else if (err == 0) {
> set_bit(QL_MSIX_ENABLED, &qdev->flags);
>--
>1.7.7.6
>
Thanks
-Jiten
[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 4756 bytes --]
^ permalink raw reply
* [PATCH net-next] openvswitch: Use ether_addr_copy
From: Joe Perches @ 2014-02-18 19:15 UTC (permalink / raw)
To: netdev; +Cc: Jesse Gross, David S. Miller, dev, linux-kernel
It's slightly smaller/faster for some architectures.
Signed-off-by: Joe Perches <joe@perches.com>
---
net/openvswitch/actions.c | 4 ++--
net/openvswitch/flow.c | 16 ++++++++--------
net/openvswitch/flow_netlink.c | 12 ++++++------
3 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index 2c77e7b..c36856a 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -134,8 +134,8 @@ static int set_eth_addr(struct sk_buff *skb,
skb_postpull_rcsum(skb, eth_hdr(skb), ETH_ALEN * 2);
- memcpy(eth_hdr(skb)->h_source, eth_key->eth_src, ETH_ALEN);
- memcpy(eth_hdr(skb)->h_dest, eth_key->eth_dst, ETH_ALEN);
+ ether_addr_copy(eth_hdr(skb)->h_source, eth_key->eth_src);
+ ether_addr_copy(eth_hdr(skb)->h_dest, eth_key->eth_dst);
ovs_skb_postpush_rcsum(skb, eth_hdr(skb), ETH_ALEN * 2);
diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index 16f4b46..bd67bb4 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -385,14 +385,14 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key,
&& opt_len == 8) {
if (unlikely(!is_zero_ether_addr(key->ipv6.nd.sll)))
goto invalid;
- memcpy(key->ipv6.nd.sll,
- &nd->opt[offset+sizeof(*nd_opt)], ETH_ALEN);
+ ether_addr_copy(key->ipv6.nd.sll,
+ &nd->opt[offset+sizeof(*nd_opt)]);
} else if (nd_opt->nd_opt_type == ND_OPT_TARGET_LL_ADDR
&& opt_len == 8) {
if (unlikely(!is_zero_ether_addr(key->ipv6.nd.tll)))
goto invalid;
- memcpy(key->ipv6.nd.tll,
- &nd->opt[offset+sizeof(*nd_opt)], ETH_ALEN);
+ ether_addr_copy(key->ipv6.nd.tll,
+ &nd->opt[offset+sizeof(*nd_opt)]);
}
icmp_len -= opt_len;
@@ -452,8 +452,8 @@ int ovs_flow_extract(struct sk_buff *skb, u16 in_port, struct sw_flow_key *key)
* header in the linear data area.
*/
eth = eth_hdr(skb);
- memcpy(key->eth.src, eth->h_source, ETH_ALEN);
- memcpy(key->eth.dst, eth->h_dest, ETH_ALEN);
+ ether_addr_copy(key->eth.src, eth->h_source);
+ ether_addr_copy(key->eth.dst, eth->h_dest);
__skb_pull(skb, 2 * ETH_ALEN);
/* We are going to push all headers that we pull, so no need to
@@ -551,8 +551,8 @@ int ovs_flow_extract(struct sk_buff *skb, u16 in_port, struct sw_flow_key *key)
key->ip.proto = ntohs(arp->ar_op);
memcpy(&key->ipv4.addr.src, arp->ar_sip, sizeof(key->ipv4.addr.src));
memcpy(&key->ipv4.addr.dst, arp->ar_tip, sizeof(key->ipv4.addr.dst));
- memcpy(key->ipv4.arp.sha, arp->ar_sha, ETH_ALEN);
- memcpy(key->ipv4.arp.tha, arp->ar_tha, ETH_ALEN);
+ ether_addr_copy(key->ipv4.arp.sha, arp->ar_sha);
+ ether_addr_copy(key->ipv4.arp.tha, arp->ar_tha);
}
} else if (key->eth.type == htons(ETH_P_IPV6)) {
int nh_len; /* IPv6 Header + Extensions */
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 4d000ac..c883b18 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -982,8 +982,8 @@ int ovs_nla_put_flow(const struct sw_flow_key *swkey,
goto nla_put_failure;
eth_key = nla_data(nla);
- memcpy(eth_key->eth_src, output->eth.src, ETH_ALEN);
- memcpy(eth_key->eth_dst, output->eth.dst, ETH_ALEN);
+ ether_addr_copy(eth_key->eth_src, output->eth.src);
+ ether_addr_copy(eth_key->eth_dst, output->eth.dst);
if (swkey->eth.tci || swkey->eth.type == htons(ETH_P_8021Q)) {
__be16 eth_type;
@@ -1055,8 +1055,8 @@ int ovs_nla_put_flow(const struct sw_flow_key *swkey,
arp_key->arp_sip = output->ipv4.addr.src;
arp_key->arp_tip = output->ipv4.addr.dst;
arp_key->arp_op = htons(output->ip.proto);
- memcpy(arp_key->arp_sha, output->ipv4.arp.sha, ETH_ALEN);
- memcpy(arp_key->arp_tha, output->ipv4.arp.tha, ETH_ALEN);
+ ether_addr_copy(arp_key->arp_sha, output->ipv4.arp.sha);
+ ether_addr_copy(arp_key->arp_tha, output->ipv4.arp.tha);
}
if ((swkey->eth.type == htons(ETH_P_IP) ||
@@ -1143,8 +1143,8 @@ int ovs_nla_put_flow(const struct sw_flow_key *swkey,
nd_key = nla_data(nla);
memcpy(nd_key->nd_target, &output->ipv6.nd.target,
sizeof(nd_key->nd_target));
- memcpy(nd_key->nd_sll, output->ipv6.nd.sll, ETH_ALEN);
- memcpy(nd_key->nd_tll, output->ipv6.nd.tll, ETH_ALEN);
+ ether_addr_copy(nd_key->nd_sll, output->ipv6.nd.sll);
+ ether_addr_copy(nd_key->nd_tll, output->ipv6.nd.tll);
}
}
}
--
1.8.1.2.459.gbcd45b4.dirty
^ permalink raw reply related
* Re: [PATCH 1/1] net: tcp: RTO restart
From: Yuchung Cheng @ 2014-02-18 18:46 UTC (permalink / raw)
To: Per Hurtig
Cc: netdev, David Miller, Eric Dumazet, Anna Brunstrom,
Andreas Petlund, Michael Welzl, Ilpo Järvinen
In-Reply-To: <20140218181205.GA7780@kau.se>
On Tue, Feb 18, 2014 at 10:12 AM, Per Hurtig <per.hurtig@kau.se> wrote:
> This patch implements the RTO restart modification described in
> http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-02
>
> RTO Restart's goal is to provide quicker loss recovery for segments lost in the
> end of a burst/connection. To accomplish this the algorithm adjusts the RTO
> value on each rearm of the retransmission timer to be exactly RTO ms after the
> earliest outstanding segment was sent. The offsetting against the earliest
> outstanding segment is not done by the regular rearm algorithm, which causes
> RTOs to occur, on average, after RTO+RTT ms.
>
> As a faster timeout is only beneficial in scenarios where fast retransmit/early
> retransmit cannot be triggered the algorithm will only kick in when there is a
> small amount of outstanding segments.
(repost in plaine-text, sorry for the duplication)
I am not sure this works well with Linux min-RTO=200ms, and don't feel
comfortable this is default on without some real experiments.
I've implemented (a nearly identical version of) rto-restart on Google
web servers and found #timeouts increased by ~30%. Although the fast
timeout helps really short flows, it has a very negative side-effect:
resetting cwnd to 1. Thus the next HTTP response may start with a
small cwnd. In contrast, TCP loss probe has fast timeout (1.5RTT) to
do fast recovery to avoid the side-effect. In other words, I am
doubtful we need rto-restart with TCP loss probe, but applying
RTO-restart on TLP timer may be useful.
I've voiced this concern multiple times in ietf tcpm discussion when
we discuss this draft: that the idea itself is fine, but we'll need to
change Linux RTO algorithm together, not just the timer itself.
I am happy to post some more detailed data if people are interested.
>
> The RTO Restart proposal is accepted as a working group item in the IETF TCP
> Maintenance and Minor Extensions (tcpm) TCP wg and is intended for experimental
> RFC status.
>
> Signed-off-by: Per Hurtig <per.hurtig@kau.se>
> ---
> include/net/tcp.h | 1 +
> net/ipv4/sysctl_net_ipv4.c | 7 +++++++
> net/ipv4/tcp_input.c | 11 +++++++++++
> 3 files changed, 19 insertions(+)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 56fc366..575e82a 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -278,6 +278,7 @@ extern int sysctl_tcp_slow_start_after_idle;
> extern int sysctl_tcp_thin_linear_timeouts;
> extern int sysctl_tcp_thin_dupack;
> extern int sysctl_tcp_early_retrans;
> +extern int sysctl_tcp_rto_restart;
> extern int sysctl_tcp_limit_output_bytes;
> extern int sysctl_tcp_challenge_ack_limit;
> extern unsigned int sysctl_tcp_notsent_lowat;
> diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
> index 44eba05..c605f4f 100644
> --- a/net/ipv4/sysctl_net_ipv4.c
> +++ b/net/ipv4/sysctl_net_ipv4.c
> @@ -717,6 +717,13 @@ static struct ctl_table ipv4_table[] = {
> .extra2 = &four,
> },
> {
> + .procname = "tcp_rto_restart",
> + .data = &sysctl_tcp_rto_restart,
> + .maxlen = sizeof(int),
> + .mode = 0644,
> + .proc_handler = proc_dointvec,
> + },
> + {
> .procname = "tcp_min_tso_segs",
> .data = &sysctl_tcp_min_tso_segs,
> .maxlen = sizeof(int),
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 227cba7..450ee30 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -98,6 +98,7 @@ int sysctl_tcp_thin_dupack __read_mostly;
>
> int sysctl_tcp_moderate_rcvbuf __read_mostly = 1;
> int sysctl_tcp_early_retrans __read_mostly = 3;
> +int sysctl_tcp_rto_restart __read_mostly = 1;
>
> #define FLAG_DATA 0x01 /* Incoming frame contained data. */
> #define FLAG_WIN_UPDATE 0x02 /* Incoming ACK was a window update. */
> @@ -2972,6 +2973,16 @@ void tcp_rearm_rto(struct sock *sk)
> */
> if (delta > 0)
> rto = delta;
> + } else if (icsk->icsk_pending == ICSK_TIME_RETRANS &&
> + sysctl_tcp_rto_restart &&
> + sk->sk_send_head == NULL &&
> + tp->packets_out < 4) {
> + struct sk_buff *skb = tcp_write_queue_head(sk);
> + const u32 rto_time_stamp = TCP_SKB_CB(skb)->when;
> + s32 delta = (s32)(tcp_time_stamp - rto_time_stamp);
> +
> + if (delta > 0)
> + rto -= delta;
> }
> inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS, rto,
> TCP_RTO_MAX);
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Xen-devel] [PATCH net-next v5 2/9] xen-netback: Change TX path from grant copy to mapping
From: David Vrabel @ 2014-02-18 18:46 UTC (permalink / raw)
To: Ian Campbell
Cc: Zoltan Kiss, xen-devel, jonathan.davies, wei.liu2, linux-kernel,
netdev
In-Reply-To: <1392745235.23084.60.camel@kazak.uk.xensource.com>
On 18/02/14 17:40, Ian Campbell wrote:
> On Mon, 2014-01-20 at 21:24 +0000, Zoltan Kiss wrote:
>>
>> @@ -344,8 +346,26 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
>> vif->pending_prod = MAX_PENDING_REQS;
>> for (i = 0; i < MAX_PENDING_REQS; i++)
>> vif->pending_ring[i] = i;
>> - for (i = 0; i < MAX_PENDING_REQS; i++)
>> - vif->mmap_pages[i] = NULL;
>> + spin_lock_init(&vif->dealloc_lock);
>> + spin_lock_init(&vif->response_lock);
>> + /* If ballooning is disabled, this will consume real memory, so you
>> + * better enable it.
>
> Almost no one who would be affected by this is going to read this
> comment. And it doesn't just require enabling ballooning, but actually
> booting with some maxmem "slack" to leave space.
>
> Classic-xen kernels used to add 8M of slop to the physical address space
> to leave a suitable pool for exactly this sort of thing. I never liked
> that but perhaps it should be reconsidered (or at least raised as a
> possibility with the core-Xen Linux guys).
I plan to fix the balloon memory hotplug stuff to do the right thing
(it's almost there -- it just tries to overlap the new memory with
existing stuff).
David
^ permalink raw reply
* [PATCH net-next] hsr: Use ether_addr_copy
From: Joe Perches @ 2014-02-18 18:37 UTC (permalink / raw)
To: netdev; +Cc: Arvid Brodin, David S. Miller, linux-kernel
It's slightly smaller/faster for some architectures.
Make sure def_multicast_addr is __aligned(2)
Signed-off-by: Joe Perches <joe@perches.com>
---
net/hsr/hsr_device.c | 10 +++++-----
net/hsr/hsr_framereg.c | 20 ++++++++++----------
net/hsr/hsr_main.c | 4 ++--
3 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/net/hsr/hsr_device.c b/net/hsr/hsr_device.c
index cac505f..e5302b7 100644
--- a/net/hsr/hsr_device.c
+++ b/net/hsr/hsr_device.c
@@ -209,7 +209,7 @@ static int slave_xmit(struct sk_buff *skb, struct hsr_priv *hsr_priv,
/* Address substitution (IEC62439-3 pp 26, 50): replace mac
* address of outgoing frame with that of the outgoing slave's.
*/
- memcpy(hsr_ethhdr->ethhdr.h_source, skb->dev->dev_addr, ETH_ALEN);
+ ether_addr_copy(hsr_ethhdr->ethhdr.h_source, skb->dev->dev_addr);
return dev_queue_xmit(skb);
}
@@ -346,7 +346,7 @@ static void send_hsr_supervision_frame(struct net_device *hsr_dev, u8 type)
/* Payload: MacAddressA */
hsr_sp = (typeof(hsr_sp)) skb_put(skb, sizeof(*hsr_sp));
- memcpy(hsr_sp->MacAddressA, hsr_dev->dev_addr, ETH_ALEN);
+ ether_addr_copy(hsr_sp->MacAddressA, hsr_dev->dev_addr);
dev_queue_xmit(skb);
return;
@@ -493,7 +493,7 @@ static int check_slave_ok(struct net_device *dev)
/* Default multicast address for HSR Supervision frames */
-static const unsigned char def_multicast_addr[ETH_ALEN] = {
+static const unsigned char def_multicast_addr[ETH_ALEN] __aligned(2) = {
0x01, 0x15, 0x4e, 0x00, 0x01, 0x00
};
@@ -519,7 +519,7 @@ int hsr_dev_finalize(struct net_device *hsr_dev, struct net_device *slave[2],
hsr_priv->announce_timer.function = hsr_announce;
hsr_priv->announce_timer.data = (unsigned long) hsr_priv;
- memcpy(hsr_priv->sup_multicast_addr, def_multicast_addr, ETH_ALEN);
+ ether_addr_copy(hsr_priv->sup_multicast_addr, def_multicast_addr);
hsr_priv->sup_multicast_addr[ETH_ALEN - 1] = multicast_spec;
/* FIXME: should I modify the value of these?
@@ -547,7 +547,7 @@ int hsr_dev_finalize(struct net_device *hsr_dev, struct net_device *slave[2],
hsr_dev->features |= NETIF_F_VLAN_CHALLENGED;
/* Set hsr_dev's MAC address to that of mac_slave1 */
- memcpy(hsr_dev->dev_addr, hsr_priv->slave[0]->dev_addr, ETH_ALEN);
+ ether_addr_copy(hsr_dev->dev_addr, hsr_priv->slave[0]->dev_addr);
/* Set required header length */
for (i = 0; i < HSR_MAX_SLAVE; i++) {
diff --git a/net/hsr/hsr_framereg.c b/net/hsr/hsr_framereg.c
index 327060c..3d0100f 100644
--- a/net/hsr/hsr_framereg.c
+++ b/net/hsr/hsr_framereg.c
@@ -108,8 +108,8 @@ int hsr_create_self_node(struct list_head *self_node_db,
if (!node)
return -ENOMEM;
- memcpy(node->MacAddressA, addr_a, ETH_ALEN);
- memcpy(node->MacAddressB, addr_b, ETH_ALEN);
+ ether_addr_copy(node->MacAddressA, addr_a);
+ ether_addr_copy(node->MacAddressB, addr_b);
rcu_read_lock();
oldnode = list_first_or_null_rcu(self_node_db,
@@ -199,7 +199,7 @@ struct node_entry *hsr_merge_node(struct hsr_priv *hsr_priv,
/* Node is known, but frame was received from an unknown
* address. Node is PICS_SUBS capable; merge its AddrB.
*/
- memcpy(node->MacAddressB, hsr_ethsup->ethhdr.h_source, ETH_ALEN);
+ ether_addr_copy(node->MacAddressB, hsr_ethsup->ethhdr.h_source);
node->AddrB_if = dev_idx;
return node;
}
@@ -208,8 +208,8 @@ struct node_entry *hsr_merge_node(struct hsr_priv *hsr_priv,
if (!node)
return NULL;
- memcpy(node->MacAddressA, hsr_sp->MacAddressA, ETH_ALEN);
- memcpy(node->MacAddressB, hsr_ethsup->ethhdr.h_source, ETH_ALEN);
+ ether_addr_copy(node->MacAddressA, hsr_sp->MacAddressA);
+ ether_addr_copy(node->MacAddressB, hsr_ethsup->ethhdr.h_source);
if (!ether_addr_equal(hsr_sp->MacAddressA, hsr_ethsup->ethhdr.h_source))
node->AddrB_if = dev_idx;
else
@@ -250,7 +250,7 @@ void hsr_addr_subst_source(struct hsr_priv *hsr_priv, struct sk_buff *skb)
rcu_read_lock();
node = find_node_by_AddrB(&hsr_priv->node_db, ethhdr->h_source);
if (node)
- memcpy(ethhdr->h_source, node->MacAddressA, ETH_ALEN);
+ ether_addr_copy(ethhdr->h_source, node->MacAddressA);
rcu_read_unlock();
}
@@ -272,7 +272,7 @@ void hsr_addr_subst_dest(struct hsr_priv *hsr_priv, struct ethhdr *ethhdr,
rcu_read_lock();
node = find_node_by_AddrA(&hsr_priv->node_db, ethhdr->h_dest);
if (node && (node->AddrB_if == dev_idx))
- memcpy(ethhdr->h_dest, node->MacAddressB, ETH_ALEN);
+ ether_addr_copy(ethhdr->h_dest, node->MacAddressB);
rcu_read_unlock();
}
@@ -428,13 +428,13 @@ void *hsr_get_next_node(struct hsr_priv *hsr_priv, void *_pos,
node = list_first_or_null_rcu(&hsr_priv->node_db,
struct node_entry, mac_list);
if (node)
- memcpy(addr, node->MacAddressA, ETH_ALEN);
+ ether_addr_copy(addr, node->MacAddressA);
return node;
}
node = _pos;
list_for_each_entry_continue_rcu(node, &hsr_priv->node_db, mac_list) {
- memcpy(addr, node->MacAddressA, ETH_ALEN);
+ ether_addr_copy(addr, node->MacAddressA);
return node;
}
@@ -462,7 +462,7 @@ int hsr_get_node_data(struct hsr_priv *hsr_priv,
return -ENOENT; /* No such entry */
}
- memcpy(addr_b, node->MacAddressB, ETH_ALEN);
+ ether_addr_copy(addr_b, node->MacAddressB);
tdiff = jiffies - node->time_in[HSR_DEV_SLAVE_A];
if (node->time_in_stale[HSR_DEV_SLAVE_A])
diff --git a/net/hsr/hsr_main.c b/net/hsr/hsr_main.c
index af68dd8..10010c5 100644
--- a/net/hsr/hsr_main.c
+++ b/net/hsr/hsr_main.c
@@ -138,8 +138,8 @@ static int hsr_netdev_notify(struct notifier_block *nb, unsigned long event,
break;
if (dev == hsr_priv->slave[0])
- memcpy(hsr_priv->dev->dev_addr,
- hsr_priv->slave[0]->dev_addr, ETH_ALEN);
+ ether_addr_copy(hsr_priv->dev->dev_addr,
+ hsr_priv->slave[0]->dev_addr);
/* Make sure we recognize frames from ourselves in hsr_rcv() */
res = hsr_create_self_node(&hsr_priv->self_node_db,
--
1.8.1.2.459.gbcd45b4.dirty
^ permalink raw reply related
* Re: [B.A.T.M.A.N.] [PATCH 01/10] batman-adv: fix soft-interface MTU computation
From: David Miller @ 2014-02-18 18:22 UTC (permalink / raw)
To: antonio; +Cc: b.a.t.m.a.n, netdev, mareklindner
In-Reply-To: <53030165.2050404@meshcoding.com>
From: Antonio Quartulli <antonio@meshcoding.com>
Date: Tue, 18 Feb 2014 07:44:53 +0100
> Unfortunately this is not the only "fake-atomic" variable we have.
:-(
> We'll send a change for this later within our pull request for net-next, ok?
Fair enough.
^ permalink raw reply
* [PATCH 1/1] net: tcp: RTO restart
From: Per Hurtig @ 2014-02-18 18:12 UTC (permalink / raw)
To: netdev, davem, edumazet; +Cc: anna.brunstrom, apetlund, michawe, ilpo.jarvinen
This patch implements the RTO restart modification described in
http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-02
RTO Restart's goal is to provide quicker loss recovery for segments lost in the
end of a burst/connection. To accomplish this the algorithm adjusts the RTO
value on each rearm of the retransmission timer to be exactly RTO ms after the
earliest outstanding segment was sent. The offsetting against the earliest
outstanding segment is not done by the regular rearm algorithm, which causes
RTOs to occur, on average, after RTO+RTT ms.
As a faster timeout is only beneficial in scenarios where fast retransmit/early
retransmit cannot be triggered the algorithm will only kick in when there is a
small amount of outstanding segments.
The RTO Restart proposal is accepted as a working group item in the IETF TCP
Maintenance and Minor Extensions (tcpm) TCP wg and is intended for experimental
RFC status.
Signed-off-by: Per Hurtig <per.hurtig@kau.se>
---
include/net/tcp.h | 1 +
net/ipv4/sysctl_net_ipv4.c | 7 +++++++
net/ipv4/tcp_input.c | 11 +++++++++++
3 files changed, 19 insertions(+)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 56fc366..575e82a 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -278,6 +278,7 @@ extern int sysctl_tcp_slow_start_after_idle;
extern int sysctl_tcp_thin_linear_timeouts;
extern int sysctl_tcp_thin_dupack;
extern int sysctl_tcp_early_retrans;
+extern int sysctl_tcp_rto_restart;
extern int sysctl_tcp_limit_output_bytes;
extern int sysctl_tcp_challenge_ack_limit;
extern unsigned int sysctl_tcp_notsent_lowat;
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 44eba05..c605f4f 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -717,6 +717,13 @@ static struct ctl_table ipv4_table[] = {
.extra2 = &four,
},
{
+ .procname = "tcp_rto_restart",
+ .data = &sysctl_tcp_rto_restart,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
.procname = "tcp_min_tso_segs",
.data = &sysctl_tcp_min_tso_segs,
.maxlen = sizeof(int),
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 227cba7..450ee30 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -98,6 +98,7 @@ int sysctl_tcp_thin_dupack __read_mostly;
int sysctl_tcp_moderate_rcvbuf __read_mostly = 1;
int sysctl_tcp_early_retrans __read_mostly = 3;
+int sysctl_tcp_rto_restart __read_mostly = 1;
#define FLAG_DATA 0x01 /* Incoming frame contained data. */
#define FLAG_WIN_UPDATE 0x02 /* Incoming ACK was a window update. */
@@ -2972,6 +2973,16 @@ void tcp_rearm_rto(struct sock *sk)
*/
if (delta > 0)
rto = delta;
+ } else if (icsk->icsk_pending == ICSK_TIME_RETRANS &&
+ sysctl_tcp_rto_restart &&
+ sk->sk_send_head == NULL &&
+ tp->packets_out < 4) {
+ struct sk_buff *skb = tcp_write_queue_head(sk);
+ const u32 rto_time_stamp = TCP_SKB_CB(skb)->when;
+ s32 delta = (s32)(tcp_time_stamp - rto_time_stamp);
+
+ if (delta > 0)
+ rto -= delta;
}
inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS, rto,
TCP_RTO_MAX);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] sh_eth: call of_mdiobus_register() to register phys
From: Sergei Shtylyov @ 2014-02-18 18:11 UTC (permalink / raw)
To: Ben Dooks; +Cc: netdev, horms+renesas, linux-sh, magnus, linux-kernel
In-Reply-To: <530383BB.60102@codethink.co.uk>
Hello.
On 02/18/2014 07:00 PM, Ben Dooks wrote:
>>>>> If the sh_eth device is registered using OF, then the driver
>>>> Which is not supported yet as my DT patch hasn't been merged.
>>>> This patch seems somewhat premature.
>>> I've got your OF patches in my local tree to test with, this
>>> is what I found during that testing.
>> The issue is that I didn't post my v3 patch to netdev due to
>> net-next.git repo being closed at this moment and DaveM not wanting to
>> see any patch targeted to it during this time. I've now posted v4 of my
>> Ether DT patch to netdev.
> Ok, I will look for these tomorrow.
No significant changes there...
>>>>> should call of_mdiobus_register() to register any PHYs connected
>>>>> to the system.
>>>> That's not necessary (but good to have).
>>> Well, it is necessary if you then want any PHYS bound to
>>> the device to have their OF information to hand,
>> Ether DT support worked for me without this fragment, at least.
> Yes, it just that the PHY is not being linked to the relevant
> OF node. The PHY gets bound, it will not be able to find the
> DT info passed.
With no DT support in the PHY driver, I don't see how it matters. Perhaps
it has to do with your "init-regs" prop patch though...
>>>>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>>>>> ---
>>>>> drivers/net/ethernet/renesas/sh_eth.c | 13 +++++++++++++
>>>>> 1 file changed, 13 insertions(+)
>>>>> diff --git a/drivers/net/ethernet/renesas/sh_eth.c
>>>>> b/drivers/net/ethernet/renesas/sh_eth.c
>>>>> index 06970ac..165f0c4 100644
>>>>> --- a/drivers/net/ethernet/renesas/sh_eth.c
>>>>> +++ b/drivers/net/ethernet/renesas/sh_eth.c
>>>> [...]
>>>>> @@ -2629,6 +2630,18 @@ static int sh_mdio_init(struct net_device
>>>>> *ndev, int id,
>>>>> snprintf(mdp->mii_bus->id, MII_BUS_ID_SIZE, "%s-%x",
>>>>> mdp->pdev->name, id);
>>>>>
>>>>> + if (ndev->dev.parent->of_node) {
>>>>> + dev_set_drvdata(&ndev->dev, mdp->mii_bus);
>>>>> + ret = of_mdiobus_register(mdp->mii_bus,
>>>>> + ndev->dev.parent->of_node);
>>>>> + if (ret != 0) {
>>>>> + dev_err(&ndev->dev, "of_mdiobus_register() failed\n");
>>>>> + goto out_free_bus;
>>>>> + }
>>> I should probably only set the drvdata if the
>>> of_mdiobus_register() succeeds.
>> Yes. Probably should use *goto* as well since in that case the
>> success path would be the same as the existing one.
> I will look into that, not the biggest fan of gotos for
> success cases.
Can also try to use *else* branch to call mdiobus_register()...
>>>>> + return 0;
>>>>> + }
>>>>> +
>>>>> /* PHY IRQ */
>>>>> mdp->mii_bus->irq = devm_kzalloc(&ndev->dev,
>>>>> sizeof(int) * PHY_MAX_ADDR,
[...]
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] of_mdio: fix phy interrupt passing
From: Sergei Shtylyov @ 2014-02-18 18:06 UTC (permalink / raw)
To: Grant Likely, Ben Dooks
Cc: linux-kernel, devicetree, linux-kernel, netdev, linux-sh
In-Reply-To: <20140218170202.424D7C40517@trevor.secretlab.ca>
Hello.
On 02/18/2014 08:02 PM, Grant Likely wrote:
>>> On Mon, 17 Feb 2014 16:29:40 +0000, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
>>>> The of_mdiobus_register_phy() is not setting phy->irq this causing
>>>> some drivers to incorrectly assume that the PHY does not have an
>>>> IRQ associated with it or install an interrupt handler for the
>>>> PHY.
>>>> Simplify the code setting irq and set the phy->irq at the same
>>>> time so that the case if mdio->irq is not NULL is easier to read.
>>>> This fixes the issue:
>>>> net eth0: attached PHY 1 (IRQ -1) to driver Micrel KSZ8041RNLI
>>>> to the correct:
>>>> net eth0: attached PHY 1 (IRQ 416) to driver Micrel KSZ8041RNLI
>>>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>>>> ---
>>>> drivers/of/of_mdio.c | 12 ++++++------
>>>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>>> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
>>>> index 875b7b6..7b3e7b0 100644
>>>> --- a/drivers/of/of_mdio.c
>>>> +++ b/drivers/of/of_mdio.c
>>>> @@ -44,7 +44,7 @@ static int of_mdiobus_register_phy(struct mii_bus *mdio, struct device_node *chi
>>>> {
>>>> struct phy_device *phy;
>>>> bool is_c45;
>>>> - int rc, prev_irq;
>>>> + int rc;
>>>> u32 max_speed = 0;
>>>>
>>>> is_c45 = of_device_is_compatible(child,
>>>> @@ -55,11 +55,11 @@ static int of_mdiobus_register_phy(struct mii_bus *mdio, struct device_node *chi
>>>> return 1;
>>>>
>>>> if (mdio->irq) {
>>>> - prev_irq = mdio->irq[addr];
>>>> - mdio->irq[addr] =
>>>> - irq_of_parse_and_map(child, 0);
>>>> - if (!mdio->irq[addr])
>>>> - mdio->irq[addr] = prev_irq;
>>> I cannot for the life for me remeber why the code was structured that
>>> way. Your change is better.
>>>> + rc = irq_of_parse_and_map(child, 0);
>>>> + if (rc > 0) {
>>>> + mdio->irq[addr] = rc;
>>>> + phy->irq = rc;
>>>> + }
>>>> }
>>> The outer if is merely protecting against no irq array being allocated
>>> for the bus. Would not the following be better:
>>> rc = irq_of_parse_and_map(child, 0);
>>> if (rc > 0) {
>>> phy->irq = rc;
>>> if (mdio->irq)
>>> mdio->irq[addr] = rc;
>>> }
>> Thanks, that makes sense, although we've both failed to work
>> out if mdio->irq is set, and rc <= 0 case, so:
>> rc = irq_of_parse_and_map(child, 0);
>> if (rc > 0) {
>> phy->irq = rc;
>> if (mdio->irq)
>> mdio->irq[addr] = rc;
>> } else {
>> if (mdio->irq)
>> phy->irq = mdio->irq[addr];
>> }
> Is this actually a valid thing to do? I think the only time mdio->irq[]
> is non-zero is when it is set to PHY_POLL. Is it valid to set phy->irq
> to PHY_POLL? I didn't think it was.
It is valid, AFAIK.
> g.
>> --
>> Ben Dooks http://www.codethink.co.uk/
>> Senior Engineer Codethink - Providing Genius
WBR, Sergei
^ permalink raw reply
* [PATCH] MAINTAINERS: add entry for the PHY library
From: Florian Fainelli @ 2014-02-18 17:47 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli, Grant Likely, Shaohui Xie, Andy Fleming
The PHY library has been subject to some changes, new drivers and DT
interactions over the past few months. Add myself as a maintainer for
the core PHY library parts and drivers. Make sure the PHY library entry
also covers the Device Tree files which have a close interaction with
the MDIO bus, PHY connection and Ethernet PHY mode parsing.
CC: Grant Likely <grant.likely@linaro.org>
CC: Shaohui Xie <shaohui.xie@freescale.com>
CC: Andy Fleming <afleming@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
MAINTAINERS | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5a7b3ec..2bfdb79 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3330,6 +3330,17 @@ S: Maintained
F: include/linux/netfilter_bridge/
F: net/bridge/
+ETHERNET PHY LIBRARY
+M: Florian Fainelli <f.fainelli@gmail.com>
+L: netdev@vger.kernel.org
+S: Maintained
+F: include/linux/phy.h
+F: include/linux/phy_fixed.h
+F: drivers/net/phy/
+F: Documentation/networking/phy.txt
+F: drivers/of/of_mdio.c
+F: drivers/of/of_net.c
+
EXT2 FILE SYSTEM
M: Jan Kara <jack@suse.cz>
L: linux-ext4@vger.kernel.org
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH net-next v5 4/9] xen-netback: Change RX path for mapped SKB fragments
From: Ian Campbell @ 2014-02-18 17:45 UTC (permalink / raw)
To: Zoltan Kiss; +Cc: wei.liu2, xen-devel, netdev, linux-kernel, jonathan.davies
In-Reply-To: <1390253069-25507-5-git-send-email-zoltan.kiss@citrix.com>
On Mon, 2014-01-20 at 21:24 +0000, Zoltan Kiss wrote:
Re the Subject: change how? Perhaps "handle foreign mapped pages on the
guest RX path" would be clearer.
> RX path need to know if the SKB fragments are stored on pages from another
> domain.
Does this not need to be done either before the mapping change or at the
same time? -- otherwise you have a window of a couple of commits where
things are broken, breaking bisectability.
>
> v4:
> - indentation fixes
>
> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
> ---
> drivers/net/xen-netback/netback.c | 46 +++++++++++++++++++++++++++++++++----
> 1 file changed, 41 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index f74fa92..d43444d 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -226,7 +226,9 @@ static struct xenvif_rx_meta *get_next_rx_buffer(struct xenvif *vif,
> static void xenvif_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> struct netrx_pending_operations *npo,
> struct page *page, unsigned long size,
> - unsigned long offset, int *head)
> + unsigned long offset, int *head,
> + struct xenvif *foreign_vif,
> + grant_ref_t foreign_gref)
> {
> struct gnttab_copy *copy_gop;
> struct xenvif_rx_meta *meta;
> @@ -268,8 +270,15 @@ static void xenvif_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> copy_gop->flags = GNTCOPY_dest_gref;
> copy_gop->len = bytes;
>
> - copy_gop->source.domid = DOMID_SELF;
> - copy_gop->source.u.gmfn = virt_to_mfn(page_address(page));
> + if (foreign_vif) {
> + copy_gop->source.domid = foreign_vif->domid;
> + copy_gop->source.u.ref = foreign_gref;
> + copy_gop->flags |= GNTCOPY_source_gref;
> + } else {
> + copy_gop->source.domid = DOMID_SELF;
> + copy_gop->source.u.gmfn =
> + virt_to_mfn(page_address(page));
> + }
> copy_gop->source.offset = offset;
>
> copy_gop->dest.domid = vif->domid;
> @@ -330,6 +339,9 @@ static int xenvif_gop_skb(struct sk_buff *skb,
> int old_meta_prod;
> int gso_type;
> int gso_size;
> + struct ubuf_info *ubuf = skb_shinfo(skb)->destructor_arg;
> + grant_ref_t foreign_grefs[MAX_SKB_FRAGS];
> + struct xenvif *foreign_vif = NULL;
>
> old_meta_prod = npo->meta_prod;
>
> @@ -370,6 +382,26 @@ static int xenvif_gop_skb(struct sk_buff *skb,
> npo->copy_off = 0;
> npo->copy_gref = req->gref;
>
> + if ((skb_shinfo(skb)->tx_flags & SKBTX_DEV_ZEROCOPY) &&
> + (ubuf->callback == &xenvif_zerocopy_callback)) {
> + u16 pending_idx = ubuf->desc;
> + int i = 0;
> + struct pending_tx_info *temp =
> + container_of(ubuf,
> + struct pending_tx_info,
> + callback_struct);
> + foreign_vif =
> + container_of(temp - pending_idx,
> + struct xenvif,
> + pending_tx_info[0]);
> + do {
> + pending_idx = ubuf->desc;
> + foreign_grefs[i++] =
> + foreign_vif->pending_tx_info[pending_idx].req.gref;
> + ubuf = (struct ubuf_info *) ubuf->ctx;
> + } while (ubuf);
> + }
> +
> data = skb->data;
> while (data < skb_tail_pointer(skb)) {
> unsigned int offset = offset_in_page(data);
> @@ -379,7 +411,9 @@ static int xenvif_gop_skb(struct sk_buff *skb,
> len = skb_tail_pointer(skb) - data;
>
> xenvif_gop_frag_copy(vif, skb, npo,
> - virt_to_page(data), len, offset, &head);
> + virt_to_page(data), len, offset, &head,
> + NULL,
> + 0);
> data += len;
> }
>
> @@ -388,7 +422,9 @@ static int xenvif_gop_skb(struct sk_buff *skb,
> skb_frag_page(&skb_shinfo(skb)->frags[i]),
> skb_frag_size(&skb_shinfo(skb)->frags[i]),
> skb_shinfo(skb)->frags[i].page_offset,
> - &head);
> + &head,
> + foreign_vif,
> + foreign_grefs[i]);
> }
>
> return npo->meta_prod - old_meta_prod;
^ permalink raw reply
* [PATCH net-next 3/3] bonding: Invert test
From: Joe Perches @ 2014-02-18 17:42 UTC (permalink / raw)
To: netdev; +Cc: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, linux-kernel
In-Reply-To: <cover.1392745013.git.joe@perches.com>
Make the error case return early.
Make the normal return at the bottom of the function.
Reduces indent for readability.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/bonding/bond_3ad.c | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
index 7cb51f9..a0e12369 100644
--- a/drivers/net/bonding/bond_3ad.c
+++ b/drivers/net/bonding/bond_3ad.c
@@ -2381,17 +2381,16 @@ int __bond_3ad_get_active_agg_info(struct bonding *bond,
}
}
- if (aggregator) {
- ad_info->aggregator_id = aggregator->aggregator_identifier;
- ad_info->ports = aggregator->num_of_ports;
- ad_info->actor_key = aggregator->actor_oper_aggregator_key;
- ad_info->partner_key = aggregator->partner_oper_aggregator_key;
- ether_addr_copy(ad_info->partner_system,
- aggregator->partner_system.mac_addr_value);
- return 0;
- }
-
- return -1;
+ if (!aggregator)
+ return -1;
+
+ ad_info->aggregator_id = aggregator->aggregator_identifier;
+ ad_info->ports = aggregator->num_of_ports;
+ ad_info->actor_key = aggregator->actor_oper_aggregator_key;
+ ad_info->partner_key = aggregator->partner_oper_aggregator_key;
+ ether_addr_copy(ad_info->partner_system,
+ aggregator->partner_system.mac_addr_value);
+ return 0;
}
/* Wrapper used to hold bond->lock so no slave manipulation can occur */
--
1.8.1.2.459.gbcd45b4.dirty
^ permalink raw reply related
* [PATCH net-next 2/3] bonding: Remove unnecessary else
From: Joe Perches @ 2014-02-18 17:42 UTC (permalink / raw)
To: netdev; +Cc: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, linux-kernel
In-Reply-To: <cover.1392745013.git.joe@perches.com>
It's unnecessary and less readable after a clause ending in a goto.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/bonding/bond_alb.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index 97a43a20..aaeeacf 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@ -1455,12 +1455,12 @@ int bond_alb_xmit(struct sk_buff *skb, struct net_device *bond_dev)
bond_dev_queue_xmit(bond, skb, tx_slave->dev);
goto out;
- } else {
- if (tx_slave) {
- _lock_tx_hashtbl(bond);
- __tlb_clear_slave(bond, tx_slave, 0);
- _unlock_tx_hashtbl(bond);
- }
+ }
+
+ if (tx_slave) {
+ _lock_tx_hashtbl(bond);
+ __tlb_clear_slave(bond, tx_slave, 0);
+ _unlock_tx_hashtbl(bond);
}
/* no suitable interface, frame not sent */
--
1.8.1.2.459.gbcd45b4.dirty
^ permalink raw reply related
* [PATCH net-next 1/3] bonding: More use of ether_addr_copy
From: Joe Perches @ 2014-02-18 17:42 UTC (permalink / raw)
To: netdev; +Cc: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, linux-kernel
In-Reply-To: <cover.1392745013.git.joe@perches.com>
It's smaller and faster for some architectures.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/bonding/bond_3ad.c | 4 ++--
drivers/net/bonding/bond_alb.c | 5 ++---
drivers/net/bonding/bond_main.c | 6 +++---
3 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
index e9edd84..7cb51f9 100644
--- a/drivers/net/bonding/bond_3ad.c
+++ b/drivers/net/bonding/bond_3ad.c
@@ -2386,8 +2386,8 @@ int __bond_3ad_get_active_agg_info(struct bonding *bond,
ad_info->ports = aggregator->num_of_ports;
ad_info->actor_key = aggregator->actor_oper_aggregator_key;
ad_info->partner_key = aggregator->partner_oper_aggregator_key;
- memcpy(ad_info->partner_system,
- aggregator->partner_system.mac_addr_value, ETH_ALEN);
+ ether_addr_copy(ad_info->partner_system,
+ aggregator->partner_system.mac_addr_value);
return 0;
}
diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index 538913e..97a43a20 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@ -1449,9 +1449,8 @@ int bond_alb_xmit(struct sk_buff *skb, struct net_device *bond_dev)
if (tx_slave && SLAVE_IS_OK(tx_slave)) {
if (tx_slave != rcu_dereference(bond->curr_active_slave)) {
- memcpy(eth_data->h_source,
- tx_slave->dev->dev_addr,
- ETH_ALEN);
+ ether_addr_copy(eth_data->h_source,
+ tx_slave->dev->dev_addr);
}
bond_dev_queue_xmit(bond, skb, tx_slave->dev);
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 3bce855..4690b11 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -674,8 +674,8 @@ static void bond_do_fail_over_mac(struct bonding *bond,
if (old_active) {
ether_addr_copy(tmp_mac, new_active->dev->dev_addr);
- memcpy(saddr.sa_data, old_active->dev->dev_addr,
- ETH_ALEN);
+ ether_addr_copy(saddr.sa_data,
+ old_active->dev->dev_addr);
saddr.sa_family = new_active->dev->type;
} else {
ether_addr_copy(saddr.sa_data, bond->dev->dev_addr);
@@ -1142,7 +1142,7 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
kfree_skb(skb);
return RX_HANDLER_CONSUMED;
}
- memcpy(eth_hdr(skb)->h_dest, bond->dev->dev_addr, ETH_ALEN);
+ ether_addr_copy(eth_hdr(skb)->h_dest, bond->dev->dev_addr);
}
return ret;
--
1.8.1.2.459.gbcd45b4.dirty
^ permalink raw reply related
* [PATCH net-next 0/3] bonding: More ether_addr_copy and neatenings.
From: Joe Perches @ 2014-02-18 17:42 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
Joe Perches (3):
bonding: More use of ether_addr_copy
bonding: Remove unnecessary else
bonding: Invert test
drivers/net/bonding/bond_3ad.c | 21 ++++++++++-----------
drivers/net/bonding/bond_alb.c | 17 ++++++++---------
drivers/net/bonding/bond_main.c | 6 +++---
3 files changed, 21 insertions(+), 23 deletions(-)
--
1.8.1.2.459.gbcd45b4.dirty
^ permalink raw reply
* Re: [PATCH net-next v5 2/9] xen-netback: Change TX path from grant copy to mapping
From: Ian Campbell @ 2014-02-18 17:40 UTC (permalink / raw)
To: Zoltan Kiss; +Cc: wei.liu2, xen-devel, netdev, linux-kernel, jonathan.davies
In-Reply-To: <1390253069-25507-3-git-send-email-zoltan.kiss@citrix.com>
On Mon, 2014-01-20 at 21:24 +0000, Zoltan Kiss wrote:
> This patch changes the grant copy on the TX patch to grant mapping
Both this and the previous patch had a single sentence commit message (I
count them together since they are split weirdly and are a single
logical change to my eyes).
Really a change of this magnitude deserves a commit message to match,
e.g. explaining the approach which is taken by the code at a high level,
what it is doing, how it is doing it, the rationale for using a kthread
etc etc.
>
> v2:
> - delete branch for handling fragmented packets fit PKT_PROT_LEN sized first
> request
> - mark the effect of using ballooned pages in a comment
> - place setting of skb_shinfo(skb)->tx_flags |= SKBTX_DEV_ZEROCOPY right
> before netif_receive_skb, and mark the importance of it
> - grab dealloc_lock before __napi_complete to avoid contention with the
> callback's napi_schedule
> - handle fragmented packets where first request < PKT_PROT_LEN
> - fix up error path when checksum_setup failed
> - check before teardown for pending grants, and start complain if they are
> there after 10 second
>
> v3:
> - delete a surplus checking from tx_action
> - remove stray line
> - squash xenvif_idx_unmap changes into the first patch
> - init spinlocks
> - call map hypercall directly instead of gnttab_map_refs()
> - fix unmapping timeout in xenvif_free()
>
> v4:
> - fix indentations and comments
> - handle errors of set_phys_to_machine
> - go back to gnttab_map_refs instead of direct hypercall. Now we rely on the
> modified API
>
> v5:
> - BUG_ON(vif->dealloc_task) in xenvif_connect
> - use 'task' in xenvif_connect for thread creation
> - proper return value if alloc_xenballooned_pages fails
> - BUG in xenvif_tx_check_gop if stale handle found
>
> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
> ---
> drivers/net/xen-netback/interface.c | 63 ++++++++-
> drivers/net/xen-netback/netback.c | 254 ++++++++++++++---------------------
> 2 files changed, 160 insertions(+), 157 deletions(-)
>
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index f0f0c3d..b3daae2 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -122,7 +122,9 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
> BUG_ON(skb->dev != dev);
>
> /* Drop the packet if vif is not ready */
> - if (vif->task == NULL || !xenvif_schedulable(vif))
> + if (vif->task == NULL ||
> + vif->dealloc_task == NULL ||
Under what conditions could this be true? Would it not represent a
rather serious failure?
> + !xenvif_schedulable(vif))
> goto drop;
>
> /* At best we'll need one slot for the header and one for each
> @@ -344,8 +346,26 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
> vif->pending_prod = MAX_PENDING_REQS;
> for (i = 0; i < MAX_PENDING_REQS; i++)
> vif->pending_ring[i] = i;
> - for (i = 0; i < MAX_PENDING_REQS; i++)
> - vif->mmap_pages[i] = NULL;
> + spin_lock_init(&vif->dealloc_lock);
> + spin_lock_init(&vif->response_lock);
> + /* If ballooning is disabled, this will consume real memory, so you
> + * better enable it.
Almost no one who would be affected by this is going to read this
comment. And it doesn't just require enabling ballooning, but actually
booting with some maxmem "slack" to leave space.
Classic-xen kernels used to add 8M of slop to the physical address space
to leave a suitable pool for exactly this sort of thing. I never liked
that but perhaps it should be reconsidered (or at least raised as a
possibility with the core-Xen Linux guys).
> The long term solution would be to use just a
> + * bunch of valid page descriptors, without dependency on ballooning
Where would these come from? Do you have a cunning plan here?
> + */
> + err = alloc_xenballooned_pages(MAX_PENDING_REQS,
> + vif->mmap_pages,
> + false);
> + if (err) {
> + netdev_err(dev, "Could not reserve mmap_pages\n");
> + return ERR_PTR(-ENOMEM);
> + }
> + for (i = 0; i < MAX_PENDING_REQS; i++) {
> + vif->pending_tx_info[i].callback_struct = (struct ubuf_info)
> + { .callback = xenvif_zerocopy_callback,
> + .ctx = NULL,
> + .desc = i };
> + vif->grant_tx_handle[i] = NETBACK_INVALID_HANDLE;
> + }
>
> /*
> * Initialise a dummy MAC address. We choose the numerically
> @@ -383,12 +403,14 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
>
> BUG_ON(vif->tx_irq);
> BUG_ON(vif->task);
> + BUG_ON(vif->dealloc_task);
>
> err = xenvif_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
> if (err < 0)
> goto err;
>
> init_waitqueue_head(&vif->wq);
> + init_waitqueue_head(&vif->dealloc_wq);
>
> if (tx_evtchn == rx_evtchn) {
> /* feature-split-event-channels == 0 */
> @@ -432,6 +454,18 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
>
> vif->task = task;
>
> + task = kthread_create(xenvif_dealloc_kthread,
> + (void *)vif,
> + "%s-dealloc",
> + vif->dev->name);
This is separate to the existing kthread that handles rx stuff. If they
cannot or should not be combined then I think the existing one needs
renaming, both the function and the thread itself in a precursor patch.
> @@ -494,6 +534,23 @@ void xenvif_disconnect(struct xenvif *vif)
>
> void xenvif_free(struct xenvif *vif)
> {
> + int i, unmap_timeout = 0;
> +
> + for (i = 0; i < MAX_PENDING_REQS; ++i) {
> + if (vif->grant_tx_handle[i] != NETBACK_INVALID_HANDLE) {
> + unmap_timeout++;
> + schedule_timeout(msecs_to_jiffies(1000));
What are we waiting for here? Have we taken any action to ensure that it
is going to happen, like kicking something?
> + if (unmap_timeout > 9 &&
Why 9? Why not rely on net_ratelimit to DTRT? Or is it normal for this
to fail at least once?
> + net_ratelimit())
> + netdev_err(vif->dev,
I thought there was a ratelimited netdev printk which combined the
limiting and the printing in one function call. Maybe I am mistaken.
> + "Page still granted! Index: %x\n",
> + i);
> + i = -1;
> + }
> + }
> +
> + free_xenballooned_pages(MAX_PENDING_REQS, vif->mmap_pages);
> +
> netif_napi_del(&vif->napi);
>
> unregister_netdev(vif->dev);
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 195602f..747b428 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -646,9 +646,12 @@ static void xenvif_tx_err(struct xenvif *vif,
> struct xen_netif_tx_request *txp, RING_IDX end)
> {
> RING_IDX cons = vif->tx.req_cons;
> + unsigned long flags;
>
> do {
> + spin_lock_irqsave(&vif->response_lock, flags);
Looking at the callers you have added it would seem more natural to
handle the locking within make_tx_response itself.
What are you locking against here? Is this different to the dealloc
lock? If the concern is the rx action stuff and the dealloc stuff
conflicting perhaps a single vif lock would make sense?
> make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
> + spin_unlock_irqrestore(&vif->response_lock, flags);
> if (cons == end)
> break;
> txp = RING_GET_REQUEST(&vif->tx, cons++);
> @@ -787,10 +790,10 @@ static inline void xenvif_tx_create_gop(struct xenvif *vif,
> sizeof(*txp));
> }
>
> -static struct gnttab_copy *xenvif_get_requests(struct xenvif *vif,
> - struct sk_buff *skb,
> - struct xen_netif_tx_request *txp,
> - struct gnttab_copy *gop)
> +static struct gnttab_map_grant_ref *xenvif_get_requests(struct xenvif *vif,
> + struct sk_buff *skb,
> + struct xen_netif_tx_request *txp,
> + struct gnttab_map_grant_ref *gop)
> {
> struct skb_shared_info *shinfo = skb_shinfo(skb);
> skb_frag_t *frags = shinfo->frags;
> @@ -909,9 +841,9 @@ err:
>
> static int xenvif_tx_check_gop(struct xenvif *vif,
> struct sk_buff *skb,
> - struct gnttab_copy **gopp)
> + struct gnttab_map_grant_ref **gopp)
> {
> - struct gnttab_copy *gop = *gopp;
> + struct gnttab_map_grant_ref *gop = *gopp;
> u16 pending_idx = *((u16 *)skb->data);
> struct skb_shared_info *shinfo = skb_shinfo(skb);
> struct pending_tx_info *tx_info;
> @@ -923,6 +855,17 @@ static int xenvif_tx_check_gop(struct xenvif *vif,
> err = gop->status;
> if (unlikely(err))
> xenvif_idx_release(vif, pending_idx, XEN_NETIF_RSP_ERROR);
> + else {
> + if (vif->grant_tx_handle[pending_idx] !=
> + NETBACK_INVALID_HANDLE) {
> + netdev_err(vif->dev,
> + "Stale mapped handle! pending_idx %x handle %x\n",
> + pending_idx,
> + vif->grant_tx_handle[pending_idx]);
> + BUG();
> + }
> + vif->grant_tx_handle[pending_idx] = gop->handle;
> + }
>
> /* Skip first skb fragment if it is on same page as header fragment. */
> start = (frag_get_pending_idx(&shinfo->frags[0]) == pending_idx);
> @@ -936,18 +879,24 @@ static int xenvif_tx_check_gop(struct xenvif *vif,
> head = tx_info->head;
>
> /* Check error status: if okay then remember grant handle. */
> - do {
> newerr = (++gop)->status;
> - if (newerr)
> - break;
> - peek = vif->pending_ring[pending_index(++head)];
> - } while (!pending_tx_is_head(vif, peek));
>
> if (likely(!newerr)) {
> + if (vif->grant_tx_handle[pending_idx] !=
> + NETBACK_INVALID_HANDLE) {
> + netdev_err(vif->dev,
> + "Stale mapped handle! pending_idx %x handle %x\n",
> + pending_idx,
> + vif->grant_tx_handle[pending_idx]);
> + BUG();
> + }
You had the same thing earlier. Perhaps a helper function would be
useful?
> + vif->grant_tx_handle[pending_idx] = gop->handle;
> /* Had a previous error? Invalidate this fragment. */
> - if (unlikely(err))
> + if (unlikely(err)) {
> + xenvif_idx_unmap(vif, pending_idx);
> xenvif_idx_release(vif, pending_idx,
> XEN_NETIF_RSP_OKAY);
Would it make sense to unmap and release in a single function? (I
Haven't looked to see if you ever do one without the other, but the next
page of diff had two more occurrences of them together)
> + }
> continue;
> }
>
> @@ -960,9 +909,11 @@ static int xenvif_tx_check_gop(struct xenvif *vif,
>
> /* First error: invalidate header and preceding fragments. */
> pending_idx = *((u16 *)skb->data);
> + xenvif_idx_unmap(vif, pending_idx);
> xenvif_idx_release(vif, pending_idx, XEN_NETIF_RSP_OKAY);
> for (j = start; j < i; j++) {
> pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
> + xenvif_idx_unmap(vif, pending_idx);
> xenvif_idx_release(vif, pending_idx,
> XEN_NETIF_RSP_OKAY);
> }
> }
> + /* FIXME: __skb_fill_page_desc set this to true because page->pfmemalloc
> + * overlaps with "index", and "mapping" is not set. I think mapping
> + * should be set. If delivered to local stack, it would drop this
> + * skb in sk_filter unless the socket has the right to use it.
What is the plan to fix this?
Is this dropping not a significant issue (TBH I'm not sure what "has the
right to use it" would entail).
> + */
> + skb->pfmemalloc = false;
> }
>
> static int xenvif_get_extras(struct xenvif *vif,
> @@ -1372,7 +1341,7 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
> @@ -1581,7 +1535,11 @@ static int xenvif_tx_submit(struct xenvif *vif)
> else if (txp->flags & XEN_NETTXF_data_validated)
> skb->ip_summed = CHECKSUM_UNNECESSARY;
>
> - xenvif_fill_frags(vif, skb);
> + xenvif_fill_frags(vif,
> + skb,
> + skb_shinfo(skb)->destructor_arg ?
> + pending_idx :
> + INVALID_PENDING_IDX
Couldn't xenvif_fill_frags calculate the 3rd argument itself given that
it has skb in hand.
> );
>
> if (skb_is_nonlinear(skb) && skb_headlen(skb) < PKT_PROT_LEN) {
> int target = min_t(int, skb->len, PKT_PROT_LEN);
> @@ -1595,6 +1553,11 @@ static int xenvif_tx_submit(struct xenvif *vif)
> if (checksum_setup(vif, skb)) {
> netdev_dbg(vif->dev,
> "Can't setup checksum in net_tx_action\n");
> + /* We have to set this flag so the dealloc thread can
> + * send the slots back
Wouldn't it be more accurate to say that we need it so that the callback
happens (which we then use to trigger the dealloc thread)?
> + */
> + if (skb_shinfo(skb)->destructor_arg)
> + skb_shinfo(skb)->tx_flags |= SKBTX_DEV_ZEROCOPY;
> kfree_skb(skb);
> continue;
> }
> @@ -1620,6 +1583,14 @@ static int xenvif_tx_submit(struct xenvif *vif)
>
> work_done++;
>
> + /* Set this flag right before netif_receive_skb, otherwise
> + * someone might think this packet already left netback, and
> + * do a skb_copy_ubufs while we are still in control of the
> + * skb. E.g. the __pskb_pull_tail earlier can do such thing.
Hrm, subtle.
Ian.
^ permalink raw reply
* Re: [PATCH] sh_eth: call of_mdiobus_register() to register phys
From: Ben Dooks @ 2014-02-18 17:39 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, horms+renesas, linux-sh, magnus, linux-kernel
In-Reply-To: <5303A26D.9050301@cogentembedded.com>
On 18/02/14 18:11, Sergei Shtylyov wrote:
> Hello.
>
> On 02/18/2014 07:00 PM, Ben Dooks wrote:
>
>>>>>> If the sh_eth device is registered using OF, then the driver
>
>>>>> Which is not supported yet as my DT patch hasn't been merged.
>>>>> This patch seems somewhat premature.
>
>>>> I've got your OF patches in my local tree to test with, this
>>>> is what I found during that testing.
>
>>> The issue is that I didn't post my v3 patch to netdev due to
>>> net-next.git repo being closed at this moment and DaveM not wanting to
>>> see any patch targeted to it during this time. I've now posted v4 of my
>>> Ether DT patch to netdev.
>
>> Ok, I will look for these tomorrow.
>
> No significant changes there...
>
>>>>>> should call of_mdiobus_register() to register any PHYs connected
>>>>>> to the system.
>
>>>>> That's not necessary (but good to have).
>
>>>> Well, it is necessary if you then want any PHYS bound to
>>>> the device to have their OF information to hand,
>
>>> Ether DT support worked for me without this fragment, at least.
>
>> Yes, it just that the PHY is not being linked to the relevant
>> OF node. The PHY gets bound, it will not be able to find the
>> DT info passed.
>
> With no DT support in the PHY driver, I don't see how it matters.
> Perhaps it has to do with your "init-regs" prop patch though...
Yes, or if we add some other properties to the PHY node to say
how to initialise the registers, such as if the PHY node had.
I am going to look in to adding led<name> initialisers to the
PHY node in case people do not like my init-regs patch.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply
* [PATCH] net: stmicro: stmac: do not grab a mutex in irq off section
From: Sebastian Andrzej Siewior @ 2014-02-18 17:34 UTC (permalink / raw)
To: Giuseppe Cavallaro; +Cc: netdev, Sebastian Andrzej Siewior
I captured this:
|libphy: stmmac-0:04 - Link is Up - 1000/Full
|BUG: sleeping function called from invalid context at kernel/mutex.c:616
|in_atomic(): 1, irqs_disabled(): 128, pid: 31, name: kworker/1:1
|CPU: 1 PID: 31 Comm: kworker/1:1 Not tainted 3.12.0-00324-g28301d2-dirty #5
|[<8042f8e8>] (mutex_lock_nested+0x28/0x3cc) from [<802a226c>] (mdiobus_read+0x38/0x64)
|[<802a226c>] (mdiobus_read+0x38/0x64) from [<802a1968>] (genphy_update_link+0x18/0x50)
|[<802a1968>] (genphy_update_link+0x18/0x50) from [<802a19ac>] (genphy_read_status+0xc/0x180)
|[<802a19ac>] (genphy_read_status+0xc/0x180) from [<8029fb0c>] (phy_init_eee+0x4c/0x2ac)
|[<8029fb0c>] (phy_init_eee+0x4c/0x2ac) from [<802a7550>] (stmmac_eee_init+0x40/0x104)
|[<802a7550>] (stmmac_eee_init+0x40/0x104) from [<802a8678>] (stmmac_adjust_link+0x118/0x228)
|[<802a8678>] (stmmac_adjust_link+0x118/0x228) from [<802a0af4>] (phy_state_machine+0x23c/0x39c)
|[<802a0af4>] (phy_state_machine+0x23c/0x39c) from [<800371b8>] (process_one_work+0x1a4/0x44c)
|[<800371b8>] (process_one_work+0x1a4/0x44c) from [<80037884>] (worker_thread+0x138/0x390)
|[<80037884>] (worker_thread+0x138/0x390) from [<8003e850>] (kthread+0xb4/0xb8)
|[<8003e850>] (kthread+0xb4/0xb8) from [<8000e5a8>] (ret_from_fork+0x14/0x2c)
|stmmac: Energy-Efficient Ethernet initialized
stmmac_eee_init() is called in other places without this lock.
phy_print_status() is just a printk() and the if condition is not
protected by the lock so I moved the unlock part just before that.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 751a73a..a514d8b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -730,6 +730,7 @@ static void stmmac_adjust_link(struct net_device *dev)
priv->speed = 0;
priv->oldduplex = -1;
}
+ spin_unlock_irqrestore(&priv->lock, flags);
if (new_state && netif_msg_link(priv))
phy_print_status(phydev);
@@ -738,8 +739,6 @@ static void stmmac_adjust_link(struct net_device *dev)
* MAC related HW registers.
*/
priv->eee_enabled = stmmac_eee_init(priv);
-
- spin_unlock_irqrestore(&priv->lock, flags);
}
/**
--
1.9.0.rc3
^ permalink raw reply related
* Re: [net-next v2 3/3] cfg80211: add MPLS and 802.21 classification
From: Arend van Spriel @ 2014-02-18 17:30 UTC (permalink / raw)
To: David Miller, mathias.kretschmer; +Cc: sw, netdev, linux-wireless
In-Reply-To: <20140217.140653.1309552047403078220.davem@davemloft.net>
On 02/17/2014 08:06 PM, David Miller wrote:
> From: "Kretschmer, Mathias" <mathias.kretschmer@fokus.fraunhofer.de>
> Date: Mon, 17 Feb 2014 17:34:34 +0000
>
>> Thought so, as well. But it seems that skb->protocol is not properly
>> set when the packet originates from a packet socket. And in our
>> case we cannot set it to a fixed etherType in the bind() call since
>> we use three different etherTypes on the same socket.
>
> So many things break if the skb->protocol isn't set correctly that I
> would consider such SKBs mal-formed.
That was my take as well, but how does the kernel code consider this?
> You can specify the protocol number in the msghdr passed into the
> send.
>
Regards,
Arend
^ permalink raw reply
* Re: [PATCH next resend] tcp: use zero-window when free_space is low
From: Eric Dumazet @ 2014-02-18 17:30 UTC (permalink / raw)
To: Florian Westphal; +Cc: David Miller, netdev, ncardwell, ycheng
In-Reply-To: <20140217205219.GH31125@breakpoint.cc>
On Mon, 2014-02-17 at 21:52 +0100, Florian Westphal wrote:
> David Miller <davem@davemloft.net> wrote:
> > From: Florian Westphal <fw@strlen.de>
> > Date: Thu, 13 Feb 2014 12:52:30 +0100
> >
> > > V1 of this patch was deferred, resending to get discussion going again.
> > > Changes since v1:
> > > - add reproducer to commit message
> > >
> > > Unfortunately I couldn't come up with something that has no magic
> > > ('allowed >> 4') value. I chose >>4 (1/16th) because it didn't cause
> > > tput limitations in my 'full-mss-sized, steady state' netcat tests.
> > >
> > > Maybe someone has better idea?
> >
> > I know this is going to be frustrating, but I've marked this 'deferred'
> > again. Please resubmit after the testing and further discussions have
> > been worked out.
>
> Thanks for letting me know. I understand why you are reluctant to just
> apply this.
>
> I will submit another patch shortly that introduces snmp counter for zero-window
> (what Eric suggested), perhaps it helps him or others to find a better solution
> in the scenario.
Sorry for the delay guys, I was on vacation.
I started the tests this morning, results in about 2/3 hours.
Thanks !
^ permalink raw reply
* Re: [PATCH net-next v5 1/9] xen-netback: Introduce TX grant map definitions
From: Ian Campbell @ 2014-02-18 17:24 UTC (permalink / raw)
To: Zoltan Kiss; +Cc: wei.liu2, xen-devel, netdev, linux-kernel, jonathan.davies
In-Reply-To: <1390253069-25507-2-git-send-email-zoltan.kiss@citrix.com>
On Mon, 2014-01-20 at 21:24 +0000, Zoltan Kiss wrote:
>
> + spinlock_t dealloc_lock;
> + spinlock_t response_lock;
Please add comments to both of these describing what bits of the
datastructure they are locking.
You might find it is clearer to group the locks and the things they
protect together rather than grouping the locks together.
Ian.
^ permalink raw reply
* Re: [PATCH] net: ethernet: remove unneeded dependency of mvneta and update help text
From: Ezequiel Garcia @ 2014-02-18 17:23 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Andrew Lunn, Jason Cooper, David S. Miller, netdev,
Gregory Clement, Sebastian Hesselbarth, linux-arm-kernel
In-Reply-To: <20140218165128.5535a9ef@skate>
On Tue, Feb 18, 2014 at 04:51:28PM +0100, Thomas Petazzoni wrote:
> On Tue, 18 Feb 2014 12:45:12 -0300, Ezequiel Garcia wrote:
>
> > > At the very end of the clean up, when even Orion5x support will be
> > > merged in mach-mvebu/, then we can certainly replace these dependencies
> > > by a "depends on ARCH_MVEBU". But for the time being, PLAT_ORION seems
> > > like the right common denominator for all these platforms.
> > >
> >
> > Last time we talked about this with Sebastian and Andrew it was decided
> > that the right choice is:
> >
> > MACH_KIRKWOOD || MACH_DOVE || MACH_ARMADA_370_XP
>
> And why not Orion5x and MV78xx0 ?
>
Ouch, I confused s/MARCH/ARCH. What I meant to say is that instead of
PLAT_ORION, it was agreed to use:
ARCH_ORION5X || ARCH_KIRKWOOD || ARCH_DOVE || ARCH_MVEBU
See here for the previous discussion:
http://www.spinics.net/lists/devicetree/msg19091.html
We discussed the issue on its own thread:
http://www.spinics.net/lists/devicetree/msg19159.html
> >
> > Which would become MACH_MVEBU.
> >
> > Of course, this is near the nitpick boundary, so AFAIC you can leave
> > PLAT_ORION as in v2, if you feel like.
>
> As I suggested previously, PLAT_ORION is what *today* controls the
> visibility of all Marvell EBU drivers. Please grep for PLAT_ORION in
> your kernel tree.
Again, it has been agreed that those are all wrong and should all
be replaced by proper ARCH_whatever. Then, we'll probably be able to
stop selecting PLAT_ORION from ARCH_MVEBU.
> So why on earth would we invent something completely
> different for mvneta?
>
I don't have a strong opinion, it just feels wrong to have a different
rule each time. If you look at the watchdog patches, you'll notice we've
changed it to depend on ARCH_whatever.
So now you propose to go with PLAT_ORION. I'm fine with either of them;
but I think we should decide between one of them and stick to it, instead
of each of us having its own rule.
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH net-next 07/14] r8152: combine PHY reset with set_speed
From: Florian Fainelli @ 2014-02-18 17:19 UTC (permalink / raw)
To: Hayes Wang
Cc: netdev, nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-usb
In-Reply-To: <1392731351-25502-8-git-send-email-hayeswang-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
Hi Hayes,
2014-02-18 5:49 GMT-08:00 Hayes Wang <hayeswang-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>:
> PHY reset is necessary after some hw settings. However, it would
> cause the linking down, and so does the set_speed function. Combine
> the PHY reset with set_speed function. That could reduce the frequency
> of linking down and accessing the PHY register.
>
> Signed-off-by: Hayes Wang <hayeswang-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
> ---
> drivers/net/usb/r8152.c | 57 ++++++++++++++++++++++++++++++++++++++-----------
> 1 file changed, 45 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index c7bae39..b3155da 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -436,6 +436,7 @@ enum rtl8152_flags {
> RTL8152_SET_RX_MODE,
> WORK_ENABLE,
> RTL8152_LINK_CHG,
> + PHY_RESET,
> };
>
> /* Define these values to match your device */
> @@ -1796,6 +1797,29 @@ static void r8152_power_cut_en(struct r8152 *tp, bool enable)
>
> }
>
> +static void rtl_phy_reset(struct r8152 *tp)
> +{
> + u16 data;
> + int i;
> +
> + clear_bit(PHY_RESET, &tp->flags);
> +
> + data = r8152_mdio_read(tp, MII_BMCR);
> +
> + /* don't reset again before the previous one complete */
> + if (data & BMCR_RESET)
> + return;
> +
> + data |= BMCR_RESET;
> + r8152_mdio_write(tp, MII_BMCR, data);
> +
> + for (i = 0; i < 50; i++) {
> + msleep(20);
> + if ((r8152_mdio_read(tp, MII_BMCR) & BMCR_RESET) == 0)
> + break;
> + }
> +}
If you implemented libphy in the driver you would not have to
duplicate that and you could use "phy_init_hw()" or
genphy_soft_reset() to perform the BMCR-based software reset.
> +
> static void rtl_clear_bp(struct r8152 *tp)
> {
> ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_0, 0);
> @@ -1854,6 +1878,7 @@ static void r8152b_hw_phy_cfg(struct r8152 *tp)
> }
>
> r8152b_disable_aldps(tp);
> + set_bit(PHY_RESET, &tp->flags);
> }
>
> static void r8152b_exit_oob(struct r8152 *tp)
> @@ -2042,6 +2067,8 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
> data = sram_read(tp, SRAM_10M_AMP2);
> data |= AMP_DN;
> sram_write(tp, SRAM_10M_AMP2, data);
> +
> + set_bit(PHY_RESET, &tp->flags);
> }
>
> static void r8153_u1u2en(struct r8152 *tp, bool enable)
> @@ -2295,12 +2322,26 @@ static int rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u16 speed, u8 duplex)
> bmcr = BMCR_ANENABLE | BMCR_ANRESTART;
> }
>
> + if (test_bit(PHY_RESET, &tp->flags))
> + bmcr |= BMCR_RESET;
> +
> if (tp->mii.supports_gmii)
> r8152_mdio_write(tp, MII_CTRL1000, gbcr);
>
> r8152_mdio_write(tp, MII_ADVERTISE, anar);
> r8152_mdio_write(tp, MII_BMCR, bmcr);
>
> + if (test_bit(PHY_RESET, &tp->flags)) {
> + int i;
> +
> + clear_bit(PHY_RESET, &tp->flags);
> + for (i = 0; i < 50; i++) {
> + msleep(20);
> + if ((r8152_mdio_read(tp, MII_BMCR) & BMCR_RESET) == 0)
> + break;
> + }
> + }
> +
> out:
>
> return ret;
> @@ -2364,6 +2405,10 @@ static void rtl_work_func_t(struct work_struct *work)
> if (test_bit(RTL8152_SET_RX_MODE, &tp->flags))
> _rtl8152_set_rx_mode(tp->netdev);
>
> +
> + if (test_bit(PHY_RESET, &tp->flags))
> + rtl_phy_reset(tp);
> +
> out1:
> return;
> }
> @@ -2459,7 +2504,6 @@ static void r8152b_enable_fc(struct r8152 *tp)
> static void r8152b_init(struct r8152 *tp)
> {
> u32 ocp_data;
> - int i;
>
> rtl_clear_bp(tp);
>
> @@ -2491,14 +2535,6 @@ static void r8152b_init(struct r8152 *tp)
> r8152b_enable_aldps(tp);
> r8152b_enable_fc(tp);
>
> - r8152_mdio_write(tp, MII_BMCR, BMCR_RESET | BMCR_ANENABLE |
> - BMCR_ANRESTART);
> - for (i = 0; i < 100; i++) {
> - udelay(100);
> - if (!(r8152_mdio_read(tp, MII_BMCR) & BMCR_RESET))
> - break;
> - }
> -
> /* enable rx aggregation */
> ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_USB_CTRL);
> ocp_data &= ~RX_AGG_DISABLE;
> @@ -2569,9 +2605,6 @@ static void r8153_init(struct r8152 *tp)
> r8153_enable_eee(tp);
> r8153_enable_aldps(tp);
> r8152b_enable_fc(tp);
> -
> - r8152_mdio_write(tp, MII_BMCR, BMCR_RESET | BMCR_ANENABLE |
> - BMCR_ANRESTART);
> }
>
> static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
> --
> 1.8.4.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: add init-regs for of_phy support
From: Mark Rutland @ 2014-02-18 17:13 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Ben Dooks, Florian Fainelli, netdev, devicetree@vger.kernel.org,
Linux-sh list, David Miller
In-Reply-To: <53039193.4010500@cogentembedded.com>
On Tue, Feb 18, 2014 at 05:00:03PM +0000, Sergei Shtylyov wrote:
> Hello.
>
> On 02/18/2014 02:54 PM, Mark Rutland wrote:
>
> >> [snip]
>
> >>>>> - fixing up some design mistake?
> >>>>> - accounting for a specific board design?
>
> >>>> Kind of both. This was invented to defy the necessity of having platform
> >>>> fixup in the DT case (where there should be no board file to place it into).
> >>>> I have already described that platform fixup necessary on the Renesas
> >>>> Lager/Koelsch boards where the LED0 signat is connected to ETH_LINK signal
> >>>> on the SoC and the PHY reset sets the LED control bits to default 0 which
> >>>> means that LED0 will be LINK/ACTIVITY signal and thus blink on activity and
> >>>> cause ETH_LINK to bounce off/on after each packet.
>
> >>>>> In any case a PHY fixup would do the job for you.
>
> >>>> Not in any case. In case of DT we have no place for it, so should invent
> >>>> something involving DT.
>
> >>> How is DT different than any machine probing mechanism here? The way
> >>> to involve DT is to do the following:
>
> >>> if (of_machine_is_compatible("renesas,foo-board-with-broken-micrel-phy"))
> >>> phy_register_fixup(&foo_board_with_broken_micrel_phy);
>
> >> Oh yes, but now I have to do that for Linux, for $BSD, and for
> >> anything else I want to run on the device. I thought dt was meant
> >> to allow us to describe the hardware.
>
> > It does allow you to describe the hardware. Arbitrary register writes
> > aren't a description of the hardware, they're a sequence of instructions
> > that tells the OS nothing about the hardware and limit the ability of an
> > OS to do something different that might be better.
>
> > It's already the case that the OS has to have some knowledge of the
> > hardware that's implicit in a binding. We don't expect to have to
> > include bytecode to tell the OS how to poke a particular UART when it
> > can figure that out from a compatible string.
>
> >> If this is the case, let's just call this linuxtree and let everyone
> >> else get on with their own thing again.
>
> > This doesn't follow at all. Any OS needs to have some understanding of
> > the hardware it will try to poke. Describing a specific sequence of
> > writes in a DT is no more operating system independent than identifying
> > the hardware and expecting the OS to have a driver for it. The
> > requirements aren't any more suited to an individual OS in either case.
>
> >> See also comment below.
>
> >>> If your machine compatible string does not allow you to uniquely
> >>> identify your machine, this is a DT problem, as this should really be
> >>> the case. If you do not want to add this code to wherever this is
> >>> relevant in arch/arm/mach-shmobile/board-*.c, neither is
> >>> drivers/net/phy/phy_device.c this the place to add it.
>
> >> So where should it be added? If we keep piling stuff into board files
> >> in arch/arm.... then we're just back to the pre-dt case and going to
> >> keep getting shouted at.
>
> > The general trend has been to allocate new compatible strings for
> > components and let individual drivers handle this.
>
> > As far as I can see your case doesn't involve any components external to
> > the PHY, so should probably live in a PHY driver. The PHY can have a
>
> It does involve LEDs which should function in the way described by their
> labels, and it does involve SoC for which ETH_LINK signal should remain stable
> and not bouncing after each packet.
Ah, I see I misunderstood.
>
> > specific compatible string with the generic string as a fallback (if it
> > works to some degree without special poking).
>
> It can but that doesn't solve this issue in any way. The issue is board
> specific, not only PHY specific.
Sure. So additional properties are required.
>
> > I don't see that we need anything board-specific.
>
> Did you read the text substantially above this in this mail for more
> complete description of the issue? We're trying to emulate the PHY *platform*
> fixup here which didn't belong with the PHY driver.
Apologies, I was indeed mistaken.
Cheers,
Mark.
^ 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