* [PATCH net-next v3] xfrm: remove useless hash_resize_mutex locks
From: Ying Xue @ 2014-08-29 9:09 UTC (permalink / raw)
To: steffen.klassert; +Cc: davem, christophe.gouault, netdev
In xfrm_state.c, hash_resize_mutex is defined as a local variable
and only used in xfrm_hash_resize() which is declared as a work
handler of xfrm.state_hash_work. But when the xfrm.state_hash_work
work is put in the global workqueue(system_wq) with schedule_work(),
the work will be really inserted in the global workqueue if it was
not already queued, otherwise, it is still left in the same position
on the the global workqueue. This means the xfrm_hash_resize() work
handler is only executed once at any time no matter how many times
its work is scheduled, that is, xfrm_hash_resize() is not called
concurrently at all, so hash_resize_mutex is redundant for us.
Cc: Christophe Gouault <christophe.gouault@6wind.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Acked-by: David S. Miller <davem@davemloft.net>
---
net/xfrm/xfrm_state.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 0ab5413..de971b6 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -97,8 +97,6 @@ static unsigned long xfrm_hash_new_size(unsigned int state_hmask)
return ((state_hmask + 1) << 1) * sizeof(struct hlist_head);
}
-static DEFINE_MUTEX(hash_resize_mutex);
-
static void xfrm_hash_resize(struct work_struct *work)
{
struct net *net = container_of(work, struct net, xfrm.state_hash_work);
@@ -107,22 +105,20 @@ static void xfrm_hash_resize(struct work_struct *work)
unsigned int nhashmask, ohashmask;
int i;
- mutex_lock(&hash_resize_mutex);
-
nsize = xfrm_hash_new_size(net->xfrm.state_hmask);
ndst = xfrm_hash_alloc(nsize);
if (!ndst)
- goto out_unlock;
+ return;
nsrc = xfrm_hash_alloc(nsize);
if (!nsrc) {
xfrm_hash_free(ndst, nsize);
- goto out_unlock;
+ return;
}
nspi = xfrm_hash_alloc(nsize);
if (!nspi) {
xfrm_hash_free(ndst, nsize);
xfrm_hash_free(nsrc, nsize);
- goto out_unlock;
+ return;
}
spin_lock_bh(&net->xfrm.xfrm_state_lock);
@@ -148,9 +144,6 @@ static void xfrm_hash_resize(struct work_struct *work)
xfrm_hash_free(odst, osize);
xfrm_hash_free(osrc, osize);
xfrm_hash_free(ospi, osize);
-
-out_unlock:
- mutex_unlock(&hash_resize_mutex);
}
static DEFINE_SPINLOCK(xfrm_state_afinfo_lock);
--
1.7.9.5
^ permalink raw reply related
* [net-next PATCH 1/1] drivers: net: cpsw: Add support for pause frames
From: Mugunthan V N @ 2014-08-29 8:56 UTC (permalink / raw)
To: netdev; +Cc: davem, Mugunthan V N
CPSW supports both rx and tx pause frames for flow control.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/ethernet/ti/cpsw.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 999fb72..81325d4 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -397,6 +397,8 @@ struct cpsw_priv {
struct cpdma_ctlr *dma;
struct cpdma_chan *txch, *rxch;
struct cpsw_ale *ale;
+ bool rx_pause;
+ bool tx_pause;
/* snapshot of IRQ numbers */
u32 irqs_table[4];
u32 num_irqs;
@@ -832,6 +834,12 @@ static void _cpsw_adjust_link(struct cpsw_slave *slave,
else if (phy->speed == 10)
mac_control |= BIT(18); /* In Band mode */
+ if (priv->rx_pause)
+ mac_control |= BIT(3);
+
+ if (priv->tx_pause)
+ mac_control |= BIT(4);
+
*link = true;
} else {
mac_control = 0;
@@ -1223,6 +1231,9 @@ static int cpsw_ndo_open(struct net_device *ndev)
/* enable statistics collection only on all ports */
__raw_writel(0x7, &priv->regs->stat_port_en);
+ /* Enable internal fifo flow control */
+ writel(0x7, &priv->regs->flow_control);
+
if (WARN_ON(!priv->data.rx_descs))
priv->data.rx_descs = 128;
@@ -1784,6 +1795,30 @@ static int cpsw_set_wol(struct net_device *ndev, struct ethtool_wolinfo *wol)
return -EOPNOTSUPP;
}
+static void cpsw_get_pauseparam(struct net_device *ndev,
+ struct ethtool_pauseparam *pause)
+{
+ struct cpsw_priv *priv = netdev_priv(ndev);
+
+ pause->autoneg = AUTONEG_DISABLE;
+ pause->rx_pause = (priv->rx_pause) ? true : false;
+ pause->tx_pause = (priv->tx_pause) ? true : false;
+}
+
+static int cpsw_set_pauseparam(struct net_device *ndev,
+ struct ethtool_pauseparam *pause)
+{
+ struct cpsw_priv *priv = netdev_priv(ndev);
+ bool link;
+
+ priv->rx_pause = (pause->rx_pause) ? true : false;
+ priv->tx_pause = (pause->tx_pause) ? true : false;
+
+ for_each_slave(priv, _cpsw_adjust_link, priv, &link);
+
+ return 0;
+}
+
static const struct ethtool_ops cpsw_ethtool_ops = {
.get_drvinfo = cpsw_get_drvinfo,
.get_msglevel = cpsw_get_msglevel,
@@ -1797,6 +1832,8 @@ static const struct ethtool_ops cpsw_ethtool_ops = {
.get_sset_count = cpsw_get_sset_count,
.get_strings = cpsw_get_strings,
.get_ethtool_stats = cpsw_get_ethtool_stats,
+ .get_pauseparam = cpsw_get_pauseparam,
+ .set_pauseparam = cpsw_set_pauseparam,
.get_wol = cpsw_get_wol,
.set_wol = cpsw_set_wol,
.get_regs_len = cpsw_get_regs_len,
--
2.1.0
^ permalink raw reply related
* Re: [PATCH net-next] xfrm: remove useless hash_resize_mutex locks
From: Ying Xue @ 2014-08-29 7:55 UTC (permalink / raw)
To: Christophe Gouault, Steffen Klassert
Cc: David S. Miller, netdev@vger.kernel.org
In-Reply-To: <CADdy8HrQZQH0stZ2P_kEbw6KmnAGLr9WgQVWHEgeUByJ6znHrQ@mail.gmail.com>
On 08/29/2014 03:42 PM, Christophe Gouault wrote:
> 2014-08-29 8:11 GMT+02:00 Steffen Klassert <steffen.klassert@secunet.com>:
>> Ccing Christophe Gouault as he currently reworks the policy
>> hashing.
>
> Thanks.
>
>> One of Christophes patches will use this mutex in a worker of
>> another work queue, so this mutex is really needed if I apply
>> his patchset. See http://patchwork.ozlabs.org/patch/383486/
>
> Yes right, the mutex is actually needed after this patch.
>
>> I tend to apply Christophes patchset after some further testing,
>> so we can't remove this mutex now.
>
>>> /* Generate new index... KAME seems to generate them ordered by cost
>>> diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
>>> index 0ab5413..de971b6 100644
>>> --- a/net/xfrm/xfrm_state.c
>>> +++ b/net/xfrm/xfrm_state.c
>>> @@ -97,8 +97,6 @@ static unsigned long xfrm_hash_new_size(unsigned int state_hmask)
>>> return ((state_hmask + 1) << 1) * sizeof(struct hlist_head);
>>> }
>>>
>>> -static DEFINE_MUTEX(hash_resize_mutex);
>>> -
>>
>> This one is still redundant, so we can remove it if there
>> are no plans to do something similar to the xfrm_state
>> hashing soon. Christophe?
>
> I have no plans to work on the xfrm_state hashing soon. I think this
> mutex can be removed.
>
OK, I will resubmit the patch again to just remove the hash_resize_mutex
lock guarding xfrm_state.
Thanks,
Ying
> Best Regards,
> Christophe
>
>
^ permalink raw reply
* Re: [PATCH net-next] xfrm: remove useless hash_resize_mutex locks
From: Christophe Gouault @ 2014-08-29 7:42 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Ying Xue, David S. Miller, netdev@vger.kernel.org
In-Reply-To: <20140829061150.GE6390@secunet.com>
2014-08-29 8:11 GMT+02:00 Steffen Klassert <steffen.klassert@secunet.com>:
> Ccing Christophe Gouault as he currently reworks the policy
> hashing.
Thanks.
> One of Christophes patches will use this mutex in a worker of
> another work queue, so this mutex is really needed if I apply
> his patchset. See http://patchwork.ozlabs.org/patch/383486/
Yes right, the mutex is actually needed after this patch.
> I tend to apply Christophes patchset after some further testing,
> so we can't remove this mutex now.
>> /* Generate new index... KAME seems to generate them ordered by cost
>> diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
>> index 0ab5413..de971b6 100644
>> --- a/net/xfrm/xfrm_state.c
>> +++ b/net/xfrm/xfrm_state.c
>> @@ -97,8 +97,6 @@ static unsigned long xfrm_hash_new_size(unsigned int state_hmask)
>> return ((state_hmask + 1) << 1) * sizeof(struct hlist_head);
>> }
>>
>> -static DEFINE_MUTEX(hash_resize_mutex);
>> -
>
> This one is still redundant, so we can remove it if there
> are no plans to do something similar to the xfrm_state
> hashing soon. Christophe?
I have no plans to work on the xfrm_state hashing soon. I think this
mutex can be removed.
Best Regards,
Christophe
^ permalink raw reply
* [PATCH net-next 5/5] sched: replace bare printks
From: Stephen Hemminger @ 2014-08-29 7:09 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger
In-Reply-To: <20140829070918.508987897@networkplumber.org>
[-- Attachment #1: act-msg.patch --]
[-- Type: text/plain, Size: 1636 bytes --]
Don't use bare printk for error messages.
Make GRED error an info level message rather than debug which
is likely to be suppressed.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/net/sched/act_ipt.c 2014-03-28 11:40:43.000000000 -0700
+++ b/net/sched/act_ipt.c 2014-08-22 16:53:33.676030680 -0700
@@ -290,10 +290,10 @@ static int __init ipt_init_module(void)
ret1 = tcf_register_action(&act_xt_ops, IPT_TAB_MASK);
if (ret1 < 0)
- printk("Failed to load xt action\n");
+ pr_err("Failed to load xt action\n");
ret2 = tcf_register_action(&act_ipt_ops, IPT_TAB_MASK);
if (ret2 < 0)
- printk("Failed to load ipt action\n");
+ pr_err("Failed to load ipt action\n");
if (ret1 < 0 && ret2 < 0) {
return ret1;
--- a/net/sched/act_mirred.c 2014-08-12 13:07:42.000000000 -0700
+++ b/net/sched/act_mirred.c 2014-08-22 16:54:07.244031579 -0700
@@ -140,7 +140,7 @@ static int tcf_mirred(struct sk_buff *sk
dev = m->tcfm_dev;
if (!dev) {
- printk_once(KERN_NOTICE "tc mirred: target device is gone\n");
+ netdev_notice(dev, "tc mirred: target device is gone\n");
goto out;
}
--- a/net/sched/sch_gred.c 2014-03-28 11:40:43.000000000 -0700
+++ b/net/sched/sch_gred.c 2014-08-22 16:54:47.720032663 -0700
@@ -456,8 +456,8 @@ static int gred_change(struct Qdisc *sch
if (table->tab[table->def])
def_prio = table->tab[table->def]->prio;
- printk(KERN_DEBUG "GRED: DP %u does not have a prio "
- "setting default to %d\n", ctl->DP, def_prio);
+ pr_info("GRED: DP %u does not have a prio "
+ "setting default to %d\n", ctl->DP, def_prio);
prio = def_prio;
} else
^ permalink raw reply
* [PATCH net-next 4/5] xfrm: replace printk with pr_ macro
From: Stephen Hemminger @ 2014-08-29 7:09 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger
In-Reply-To: <20140829070918.508987897@networkplumber.org>
[-- Attachment #1: xfrm-msg.patch --]
[-- Type: text/plain, Size: 1123 bytes --]
Use standard macro's for notices.
Silence useless debug message on module load.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/net/xfrm/xfrm_user.c 2014-08-12 13:07:42.000000000 -0700
+++ b/net/xfrm/xfrm_user.c 2014-08-22 16:51:45.060027772 -0700
@@ -2582,8 +2582,7 @@ static int xfrm_send_state_notify(struct
case XFRM_MSG_FLUSHSA:
return xfrm_notify_sa_flush(c);
default:
- printk(KERN_NOTICE "xfrm_user: Unknown SA event %d\n",
- c->event);
+ pr_notice("xfrm_user: Unknown SA event %d\n", c->event);
break;
}
@@ -2875,8 +2874,7 @@ static int xfrm_send_policy_notify(struc
case XFRM_MSG_POLEXPIRE:
return xfrm_exp_policy_notify(xp, dir, c);
default:
- printk(KERN_NOTICE "xfrm_user: Unknown Policy event %d\n",
- c->event);
+ pr_notice("xfrm_user: Unknown Policy event %d\n", c->event);
}
return 0;
@@ -3031,7 +3029,7 @@ static int __init xfrm_user_init(void)
{
int rv;
- printk(KERN_INFO "Initializing XFRM netlink socket\n");
+ pr_debug("Initializing XFRM netlink socket\n");
rv = register_pernet_subsys(&xfrm_user_net_ops);
if (rv < 0)
^ permalink raw reply
* [PATCH net-next 3/5] ipv6: silence tunnel loading messages
From: Stephen Hemminger @ 2014-08-29 7:09 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger
In-Reply-To: <20140829070918.508987897@networkplumber.org>
[-- Attachment #1: ipv6-dbg-msg.patch --]
[-- Type: text/plain, Size: 1219 bytes --]
Chatter on boot is not necessary, change it to debug.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/net/ipv6/ip6_gre.c 2014-08-25 15:06:29.711056058 -0700
+++ b/net/ipv6/ip6_gre.c 2014-08-25 15:06:29.707056037 -0700
@@ -1678,7 +1678,7 @@ static int __init ip6gre_init(void)
{
int err;
- pr_info("GRE over IPv6 tunneling driver\n");
+ pr_debug("GRE over IPv6 tunneling driver\n");
err = register_pernet_device(&ip6gre_net_ops);
if (err < 0)
--- a/net/ipv6/mip6.c 2014-08-25 15:06:29.711056058 -0700
+++ b/net/ipv6/mip6.c 2014-08-25 15:06:29.707056037 -0700
@@ -482,7 +482,7 @@ static const struct xfrm_type mip6_rthdr
static int __init mip6_init(void)
{
- pr_info("Mobile IPv6\n");
+ pr_debug("Mobile IPv6\n");
if (xfrm_register_type(&mip6_destopt_type, AF_INET6) < 0) {
pr_info("%s: can't add xfrm type(destopt)\n", __func__);
--- a/net/ipv6/sit.c 2014-08-25 15:06:29.711056058 -0700
+++ b/net/ipv6/sit.c 2014-08-25 15:06:29.707056037 -0700
@@ -1796,7 +1796,7 @@ static int __init sit_init(void)
{
int err;
- pr_info("IPv6 over IPv4 tunneling driver\n");
+ pr_debug("IPv6 over IPv4 tunneling driver\n");
err = register_pernet_device(&sit_net_ops);
if (err < 0)
^ permalink raw reply
* [PATCH net-next 2/5] tcp: silence useless debug message
From: Stephen Hemminger @ 2014-08-29 7:09 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger
In-Reply-To: <20140829070918.508987897@networkplumber.org>
[-- Attachment #1: tcp-nomsg.patch --]
[-- Type: text/plain, Size: 485 bytes --]
This message isn't really needed.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/net/ipv4/tcp_cong.c 2014-05-05 23:44:19.000000000 -0700
+++ b/net/ipv4/tcp_cong.c 2014-08-22 06:33:06.067542809 -0700
@@ -51,7 +51,7 @@ int tcp_register_congestion_control(stru
ret = -EEXIST;
} else {
list_add_tail_rcu(&ca->list, &tcp_cong_list);
- pr_info("%s registered\n", ca->name);
+ pr_debug("%s registered\n", ca->name);
}
spin_unlock(&tcp_cong_list_lock);
^ permalink raw reply
* [PATCH net-next 1/5] net: fix message priorities
From: Stephen Hemminger @ 2014-08-29 7:09 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger
In-Reply-To: <20140829070918.508987897@networkplumber.org>
[-- Attachment #1: net-dbg-msg.patch --]
[-- Type: text/plain, Size: 1117 bytes --]
Using obsolete socket type should be notice not info level.
Registering is normal and should only be debug level.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/net/socket.c 2014-08-12 13:07:42.000000000 -0700
+++ b/net/socket.c 2014-08-23 10:44:47.118408989 -0700
@@ -1276,8 +1276,8 @@ int __sock_create(struct net *net, int f
static int warned;
if (!warned) {
warned = 1;
- pr_info("%s uses obsolete (PF_INET,SOCK_PACKET)\n",
- current->comm);
+ pr_notice("%s uses obsolete (PF_INET,SOCK_PACKET)\n",
+ current->comm);
}
family = PF_PACKET;
}
@@ -2624,7 +2624,7 @@ int sock_register(const struct net_proto
}
spin_unlock(&net_family_lock);
- pr_info("NET: Registered protocol family %d\n", ops->family);
+ pr_debug("NET: Registered protocol family %d\n", ops->family);
return err;
}
EXPORT_SYMBOL(sock_register);
@@ -2652,7 +2652,7 @@ void sock_unregister(int family)
synchronize_rcu();
- pr_info("NET: Unregistered protocol family %d\n", family);
+ pr_debug("NET: Unregistered protocol family %d\n", family);
}
EXPORT_SYMBOL(sock_unregister);
^ permalink raw reply
* [PATCH net-next 0/5] printk message cleanup's
From: Stephen Hemminger @ 2014-08-29 7:09 UTC (permalink / raw)
To: davem; +Cc: netdev
To support space and clutter reduction get rid of some useless
messages on boot, and be more precise about message level,
and don't use bare printk in network code.
^ permalink raw reply
* [PATCH net-next] tcp: whitespace fixes
From: Stephen Hemminger @ 2014-08-29 7:06 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Fix places where there is space before tab, long lines, and
awkward if(){.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/net/ipv4/tcp_bic.c 2014-05-05 23:44:19.000000000 -0700
+++ b/net/ipv4/tcp_bic.c 2014-08-22 17:17:51.448069718 -0700
@@ -50,7 +50,7 @@ MODULE_PARM_DESC(smooth_part, "log(B/(B*
/* BIC TCP Parameters */
struct bictcp {
u32 cnt; /* increase cwnd by 1 after ACKs */
- u32 last_max_cwnd; /* last maximum snd_cwnd */
+ u32 last_max_cwnd; /* last maximum snd_cwnd */
u32 loss_cwnd; /* congestion window at last loss */
u32 last_cwnd; /* the last snd_cwnd */
u32 last_time; /* time when updated last_cwnd */
@@ -103,7 +103,7 @@ static inline void bictcp_update(struct
/* binary increase */
if (cwnd < ca->last_max_cwnd) {
- __u32 dist = (ca->last_max_cwnd - cwnd)
+ __u32 dist = (ca->last_max_cwnd - cwnd)
/ BICTCP_B;
if (dist > max_increment)
--- a/net/ipv4/tcp_cubic.c 2014-06-16 14:48:29.000000000 -0700
+++ b/net/ipv4/tcp_cubic.c 2014-08-22 17:20:10.368073438 -0700
@@ -82,7 +82,7 @@ MODULE_PARM_DESC(hystart_ack_delta, "spa
/* BIC TCP Parameters */
struct bictcp {
u32 cnt; /* increase cwnd by 1 after ACKs */
- u32 last_max_cwnd; /* last maximum snd_cwnd */
+ u32 last_max_cwnd; /* last maximum snd_cwnd */
u32 loss_cwnd; /* congestion window at last loss */
u32 last_cwnd; /* the last snd_cwnd */
u32 last_time; /* time when updated last_cwnd */
@@ -263,9 +263,9 @@ static inline void bictcp_update(struct
/* c/rtt * (t-K)^3 */
delta = (cube_rtt_scale * offs * offs * offs) >> (10+3*BICTCP_HZ);
- if (t < ca->bic_K) /* below origin*/
+ if (t < ca->bic_K) /* below origin*/
bic_target = ca->bic_origin_point - delta;
- else /* above origin*/
+ else /* above origin*/
bic_target = ca->bic_origin_point + delta;
/* cubic function - calc bictcp_cnt*/
@@ -291,7 +291,7 @@ static inline void bictcp_update(struct
ca->tcp_cwnd++;
}
- if (ca->tcp_cwnd > cwnd){ /* if bic is slower than tcp */
+ if (ca->tcp_cwnd > cwnd) { /* if bic is slower than tcp */
delta = ca->tcp_cwnd - cwnd;
max_cnt = cwnd / delta;
if (ca->cnt > max_cnt)
@@ -452,7 +452,7 @@ static int __init cubictcp_register(void
* based on SRTT of 100ms
*/
- beta_scale = 8*(BICTCP_BETA_SCALE+beta)/ 3 / (BICTCP_BETA_SCALE - beta);
+ beta_scale = 8*(BICTCP_BETA_SCALE+beta) / 3 / (BICTCP_BETA_SCALE - beta);
cube_rtt_scale = (bic_scale * 10); /* 1024*c/rtt */
--- a/net/ipv4/tcp_yeah.c 2014-05-05 23:44:19.000000000 -0700
+++ b/net/ipv4/tcp_yeah.c 2014-08-22 17:15:47.788066407 -0700
@@ -84,7 +84,7 @@ static void tcp_yeah_cong_avoid(struct s
/* Scalable */
tp->snd_cwnd_cnt += yeah->pkts_acked;
- if (tp->snd_cwnd_cnt > min(tp->snd_cwnd, TCP_SCALABLE_AI_CNT)){
+ if (tp->snd_cwnd_cnt > min(tp->snd_cwnd, TCP_SCALABLE_AI_CNT)) {
if (tp->snd_cwnd < tp->snd_cwnd_clamp)
tp->snd_cwnd++;
tp->snd_cwnd_cnt = 0;
^ permalink raw reply
* Re: [patch net-next RFC 12/12] rocker: introduce rocker switch driver
From: Jiri Pirko @ 2014-08-29 7:06 UTC (permalink / raw)
To: Thomas Graf
Cc: netdev, davem, nhorman, andy, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, dev, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye
In-Reply-To: <20140823140450.GA24116@casper.infradead.org>
Sat, Aug 23, 2014 at 04:04:50PM CEST, tgraf@suug.ch wrote:
>On 08/21/14 at 06:19pm, Jiri Pirko wrote:
>> This patch introduces the first driver to benefit from the switchdev
>> infrastructure and to implement newly introduced switch ndos. This is a
>> driver for emulated switch chip implemented in qemu:
>> https://github.com/sfeldma/qemu-rocker/
>
>The design looks very clean. I noticed that the TLV API is almost an
>exact dupliate of the Netlink attributes API. Any specific reason for
>not reusing lib/nlattr.c and add what is missing?
Well the api is almost the same. But the implementation is different.
See for example rocker_tlv_put. It works directly with desc info.
But nla_put works with skb which is not convenient for rocker.
Also, struct nlattr is 2xu16 but struct rocker_tlv is u32 u16
^ permalink raw reply
* Re: [patch net-next RFC 06/12] net: introduce dummy switch
From: Jiri Pirko @ 2014-08-29 7:00 UTC (permalink / raw)
To: Andy Gospodarek
Cc: ryazanov.s.a-Re5JQEeQqe8AvxtiuMwx3w,
jasowang-H+wXaHxf7aLQT0dZR+AlfA,
john.r.fastabend-ral2JQCrhuEAvxtiuMwx3w,
Neil.Jerram-QnUH15yq9NYqDJ6do+/SaQ,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, andy-QlMahl40kYEqcZcGjlUOXw,
dev-yBygre7rU0TnMu66kgdUjQ, nbd-p3rKhJxN3npAfugRpC6u6w,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, ronye-VPRAkNaXOzVWk0Htik3J/w,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
ogerlitz-VPRAkNaXOzVWk0Htik3J/w, ben-/+tVBieCtBitmTQ+vhA3Yw,
buytenh-OLH4Qvv75CYX/NnBR394Jw,
roopa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR,
jhs-jkUAjuhPggJWk0Htik3J/w, aviadr-VPRAkNaXOzVWk0Htik3J/w,
nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w,
vyasevic-H+wXaHxf7aLQT0dZR+AlfA, nhorman-2XuSBdqkA4R54TAoqtyWWQ,
netdev-u79uwXL29TY76Z2rM5mHXA,
stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
dborkman-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <20140826191420.GC5275-Me9pkO/C/lgvPfuUPAiksl6hYfS7NtTn@public.gmane.org>
Tue, Aug 26, 2014 at 09:14:20PM CEST, gospo-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org wrote:
>On Thu, Aug 21, 2014 at 06:18:59PM +0200, Jiri Pirko wrote:
>> Dummy switch implementation using switchdev interface
>>
>[...]
>> + if (!data || !data[IFLA_DYMMYSWPORT_PHYS_SWITCH_ID])
>[...]
>> + dsp->psid.id_len = nla_len(data[IFLA_DYMMYSWPORT_PHYS_SWITCH_ID]);
>> + memcpy(dsp->psid.id, nla_data(data[IFLA_DYMMYSWPORT_PHYS_SWITCH_ID]),
>[...]
>> + [IFLA_DYMMYSWPORT_PHYS_SWITCH_ID] = { .type = NLA_BINARY,
>[...]
>> + IFLA_DYMMYSWPORT_PHYS_SWITCH_ID,
>I realize this does compile, but I suspect this was a typo?
Fixed. Thanks.
>
>
^ permalink raw reply
* Re: [PATCH net-next] xfrm: remove useless hash_resize_mutex locks
From: Steffen Klassert @ 2014-08-29 6:11 UTC (permalink / raw)
To: Ying Xue; +Cc: davem, netdev, Christophe Gouault
In-Reply-To: <1409132986-12224-1-git-send-email-ying.xue@windriver.com>
Ccing Christophe Gouault as he currently reworks the policy
hashing.
On Wed, Aug 27, 2014 at 05:49:46PM +0800, Ying Xue wrote:
> In xfrm_policy.c, hash_resize_mutex is defined as a local variable
> and only used in xfrm_hash_resize() which is declared as a work
> handler of xfrm.policy_hash_work. But when the xfrm.policy_hash_work
> work is put in the global workqueue(system_wq) with schedule_work(),
> the work will be really inserted in the global workqueue if it was
> not already queued, otherwise, it is still left in the same position
> on the the global workqueue. This means the xfrm_hash_resize() work
> handler is only executed once at any time no matter how many times
> its work is scheduled, that is, xfrm_hash_resize() is not called
> concurrently at all, so hash_resize_mutex is redundant for us.
>
> Additionally hash_resize_mutex defined in xfrm_state.c can be removed
> as the same reason.
>
> Signed-off-by: Ying Xue <ying.xue@windriver.com>
> Acked-by: David S. Miller <davem@davemloft.net>
> ---
> Just resend the patch after RFC flag is removed from below
> version:
> http://patchwork.ozlabs.org/patch/369818/
>
> net/xfrm/xfrm_policy.c | 5 -----
> net/xfrm/xfrm_state.c | 13 +++----------
> 2 files changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
> index beeed60..b559a90 100644
> --- a/net/xfrm/xfrm_policy.c
> +++ b/net/xfrm/xfrm_policy.c
> @@ -510,14 +510,11 @@ void xfrm_spd_getinfo(struct net *net, struct xfrmk_spdinfo *si)
> }
> EXPORT_SYMBOL(xfrm_spd_getinfo);
>
> -static DEFINE_MUTEX(hash_resize_mutex);
> static void xfrm_hash_resize(struct work_struct *work)
> {
> struct net *net = container_of(work, struct net, xfrm.policy_hash_work);
> int dir, total;
>
> - mutex_lock(&hash_resize_mutex);
One of Christophes patches will use this mutex in a worker of
another work queue, so this mutex is really needed if I apply
his patchset. See http://patchwork.ozlabs.org/patch/383486/
I tend to apply Christophes patchset after some further testing,
so we can't remove this mutex now.
>
> /* Generate new index... KAME seems to generate them ordered by cost
> diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
> index 0ab5413..de971b6 100644
> --- a/net/xfrm/xfrm_state.c
> +++ b/net/xfrm/xfrm_state.c
> @@ -97,8 +97,6 @@ static unsigned long xfrm_hash_new_size(unsigned int state_hmask)
> return ((state_hmask + 1) << 1) * sizeof(struct hlist_head);
> }
>
> -static DEFINE_MUTEX(hash_resize_mutex);
> -
This one is still redundant, so we can remove it if there
are no plans to do something similar to the xfrm_state
hashing soon. Christophe?
^ permalink raw reply
* Re: net_ns cleanup / RCU overhead
From: Julian Anastasov @ 2014-08-29 3:57 UTC (permalink / raw)
To: Simon Kirby; +Cc: Paul E. McKenney, Eric W. Biederman, linux-kernel, netdev
In-Reply-To: <20140829004029.GA18300@hostway.ca>
Hello,
On Thu, 28 Aug 2014, Simon Kirby wrote:
> I noticed that [kworker/u16:0]'s stack is often:
>
> [<ffffffff810942a6>] wait_rcu_gp+0x46/0x50
> [<ffffffff8109607e>] synchronize_sched+0x2e/0x50
> [<ffffffffa00385ac>] nf_nat_net_exit+0x2c/0x50 [nf_nat]
I guess the problem is in nf_nat_net_exit,
may be other nf exit handlers too. pernet-exit handlers
should avoid synchronize_rcu and rcu_barrier.
A RCU callback and rcu_barrier in module-exit is the way
to go. cleanup_net includes rcu_barrier, so pernet-exit
does not need such calls.
> [<ffffffff81720339>] ops_exit_list.isra.4+0x39/0x60
> [<ffffffff817209e0>] cleanup_net+0xf0/0x1a0
> [<ffffffff81062997>] process_one_work+0x157/0x440
> [<ffffffff81063303>] worker_thread+0x63/0x520
> [<ffffffff81068b96>] kthread+0xd6/0xf0
> [<ffffffff818d412c>] ret_from_fork+0x7c/0xb0
> [<ffffffffffffffff>] 0xffffffffffffffff
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH net v4 4/4] tg3: Fix tx_pending checks for tg3_tso_bug
From: Prashant Sreedharan @ 2014-08-29 3:24 UTC (permalink / raw)
To: Benjamin Poirier; +Cc: Michael Chan, netdev, linux-kernel
In-Reply-To: <1409187858-7698-4-git-send-email-bpoirier@suse.de>
>
> - for (i = 0; i < tp->irq_max; i++)
> - tp->napi[i].tx_pending = ering->tx_pending;
> + dev->gso_max_segs = TG3_TX_SEG_PER_DESC(ering->tx_pending - 1);
> + for (i = 0; i < tp->irq_max; i++) {
> + struct tg3_napi *tnapi = &tp->napi[i];
> +
> + tnapi->tx_pending = ering->tx_pending;
> + if (netif_tx_queue_stopped(netdev_get_tx_queue(dev, i)) &&
Need to limit the number of TX queues to tp->txq_cnt instead of
tp->irq_max as txq_cnt can be less than irq_max.
netif_set_real_num_tx_queues(tp->dev, tp->txq_cnt);
> + tnapi->wakeup_thresh >= ering->tx_pending)
> + tnapi->wakeup_thresh = MAX_SKB_FRAGS + 1;
> + }
>
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
From: Jason Wang @ 2014-08-29 3:08 UTC (permalink / raw)
To: Ingo Molnar
Cc: Mike Galbraith, davem, netdev, linux-kernel, mst, Peter Zijlstra,
Ingo Molnar
In-Reply-To: <20140822074224.GB7372@gmail.com>
On 08/22/2014 03:42 PM, Ingo Molnar wrote:
> * Jason Wang <jasowang@redhat.com> wrote:
>
>> Polling could be done by either rx busy loop in process
>> context or NAPI in softirq. [...]
> Note that this shows another reason why it's a bad idea to
> query nr_running directly: depending on the softirq processing
> method, a softirq might run:
>
> - directly in process context
> - in an idle thread's context
> - or in a ksoftirqd context.
>
> 'nr_running' will have different values in these cases, causing
> assymetries in busy-poll handling!
Current rx busy polling code only works in process context, we can add
BUG or warnings to make sure the helper was only called in process context.
>
> Another class of assymetry is when there are other softirq bits
> pending, beyond NET_RX (or NET_TX): a nr_running check misses
> them.
Yes, but rx busy polling only works in process context and does not
disable bh, so it may be not an issue.
> The solution I outlined in the previous mail (using a
> sched_expected_runtime() method) would be able to avoid most of
> these artifacts.
It only take cares the remaining runnable time for current process, this
is a good hint for sk_busy_loop_end_time() which return the maximum time
a process could do busy polling. But this is not this patch needs. We
need check the state of other runnable process in current cpu to avoid
damaging the performance of other process.
>
> Thanks,
>
> Ingo
> --
> 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: [PATCH net v4 4/4] tg3: Fix tx_pending checks for tg3_tso_bug
From: Prashant Sreedharan @ 2014-08-29 2:45 UTC (permalink / raw)
To: Benjamin Poirier; +Cc: Michael Chan, netdev, linux-kernel
In-Reply-To: <1409187858-7698-4-git-send-email-bpoirier@suse.de>
> if (netif_running(dev)) {
> @@ -12346,8 +12380,15 @@ static int tg3_set_ringparam(struct net_device *dev, struct ethtool_ringparam *e
> if (tg3_flag(tp, JUMBO_RING_ENABLE))
> tp->rx_jumbo_pending = ering->rx_jumbo_pending;
>
> - for (i = 0; i < tp->irq_max; i++)
> - tp->napi[i].tx_pending = ering->tx_pending;
> + dev->gso_max_segs = TG3_TX_SEG_PER_DESC(ering->tx_pending - 1);
> + for (i = 0; i < tp->irq_max; i++) {
> + struct tg3_napi *tnapi = &tp->napi[i];
> +
> + tnapi->tx_pending = ering->tx_pending;
> + if (netif_tx_queue_stopped(netdev_get_tx_queue(dev, i)) &&
> + tnapi->wakeup_thresh >= ering->tx_pending)
> + tnapi->wakeup_thresh = MAX_SKB_FRAGS + 1;
To maintain consistency wakeup_thresh can be set to TG3_TX_WAKEUP_THRESH
similar to other parts of the code, except the special handling of
tg3_tso_bug() estimate.
> + }
>
> if (netif_running(dev)) {
> tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
> @@ -17822,6 +17863,7 @@ static int tg3_init_one(struct pci_dev *pdev,
> else
> sndmbx += 0xc;
> }
^ permalink raw reply
* RE: [PATCH 0/4] net: stmmac: Enable Intel Quark SoC X1000 Ethernet support
From: Kweh, Hock Leong @ 2014-08-29 1:28 UTC (permalink / raw)
To: Giuseppe CAVALLARO, David S. Miller
Cc: netdev@vger.kernel.org, LKML, Ong, Boon Leong, Rayagond K
In-Reply-To: <53FDD4A4.5020603@st.com>
> -----Original Message-----
> From: Giuseppe CAVALLARO [mailto:peppe.cavallaro@st.com]
> Sent: Wednesday, August 27, 2014 8:53 PM
> To: Kweh, Hock Leong; David S. Miller
> Cc: netdev@vger.kernel.org; LKML; Ong, Boon Leong; Rayagond K
> Subject: Re: [PATCH 0/4] net: stmmac: Enable Intel Quark SoC X1000 Ethernet
> support
>
> On 8/27/2014 12:32 PM, Kweh Hock Leong wrote:
>
> hello and thx for these patches that at first glance look ok to me.
> Just some minor remark, in the stmmac I try to align the function parameters
> with the open parenthesis (devm_kzalloc in your case in not aligned).
> Added on copy also Rayagond he tested PCI. I cannot do any test because I
> have no PCI cards.
>
> peppe
>
Hi, noted and will update that in the v2 patch. Looking forward to get more feedback
before sending out the second version. Thanks.
Regards,
Wilson
^ permalink raw reply
* Re: net_ns cleanup / RCU overhead
From: Simon Kirby @ 2014-08-29 0:40 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: Eric W. Biederman, linux-kernel, netdev
In-Reply-To: <20140828204658.GL5001@linux.vnet.ibm.com>
On Thu, Aug 28, 2014 at 01:46:58PM -0700, Paul E. McKenney wrote:
> On Thu, Aug 28, 2014 at 03:33:42PM -0500, Eric W. Biederman wrote:
>
> > I just want to add a little bit more analysis to this.
> >
> > What we desire to be fast is the copy_net_ns, cleanup_net is batched and
> > asynchronous which nothing really cares how long it takes except that
> > cleanup_net holds the net_mutex and thus blocks copy_net_ns.
> >
> > The puzzle is why and which rcu delays Simon is seeing in the network
> > namespace cleanup path, as it seems like the synchronize_rcu is not
> > the only one, and in the case of vsftp with trivail network namespaces
> > where nothing has been done we should not need to delay.
>
> Indeed, given the version and .config, I can't see why any individual
> RCU grace-period operation would be particularly slow.
>
> I suggest using ftrace on synchronize_rcu() and friends.
I made a parallel net namespace create/destroy benchmark that prints the
progress and time to create and cleanup 32 unshare()d child processes:
http://0x.ca/sim/ref/tools/netnsbench.c
I noticed that if I haven't run it for a while, the first batch often is
fast, followed by slowness from then on:
++++++++++++++++++++++++++++++++-------------------------------- 0.039478s
++++++++++++++++++++-----+----------------+++++++++---------++-- 4.463837s
+++++++++++++++++++++++++------+--------------------++++++------ 3.011882s
+++++++++++++++---+-------------++++++++++++++++---------------- 2.283993s
Fiddling around on a stock kernel, "echo 1 > /sys/kernel/rcu_expedited"
makes behaviour change as it did with my patch:
++-++-+++-+-----+-+-++-+-++--++-+--+-+-++--++-+-+-+-++-+--++---- 0.801406s
+-+-+-++-+-+-+-+-++--+-+-++-+--++-+-+-+-+-+-+-+-+-+-+-+--++-+--- 0.872011s
++--+-++--+-++--+-++--+-+-+-+-++-+--++--+-++-+-+-+-+--++-+-+-+-- 0.946745s
How would I use ftrace on synchronize_rcu() here?
As Eric said, cleanup_net() is batched, but while it is cleaning up,
net_mutex is held. Isn't the issue just that net_mutex is held while
some other things are going on that are meant to be lazy / batched?
What is net_mutex protecting in cleanup_net()?
I noticed that [kworker/u16:0]'s stack is often:
[<ffffffff810942a6>] wait_rcu_gp+0x46/0x50
[<ffffffff8109607e>] synchronize_sched+0x2e/0x50
[<ffffffffa00385ac>] nf_nat_net_exit+0x2c/0x50 [nf_nat]
[<ffffffff81720339>] ops_exit_list.isra.4+0x39/0x60
[<ffffffff817209e0>] cleanup_net+0xf0/0x1a0
[<ffffffff81062997>] process_one_work+0x157/0x440
[<ffffffff81063303>] worker_thread+0x63/0x520
[<ffffffff81068b96>] kthread+0xd6/0xf0
[<ffffffff818d412c>] ret_from_fork+0x7c/0xb0
[<ffffffffffffffff>] 0xffffffffffffffff
and
[<ffffffff81095364>] _rcu_barrier+0x154/0x1f0
[<ffffffff81095450>] rcu_barrier+0x10/0x20
[<ffffffff81102c2c>] kmem_cache_destroy+0x6c/0xb0
[<ffffffffa0089e97>] nf_conntrack_cleanup_net_list+0x167/0x1c0 [nf_conntrack]
[<ffffffffa008aab5>] nf_conntrack_pernet_exit+0x65/0x70 [nf_conntrack]
[<ffffffff81720353>] ops_exit_list.isra.4+0x53/0x60
[<ffffffff817209e0>] cleanup_net+0xf0/0x1a0
[<ffffffff81062997>] process_one_work+0x157/0x440
[<ffffffff81063303>] worker_thread+0x63/0x520
[<ffffffff81068b96>] kthread+0xd6/0xf0
[<ffffffff818d412c>] ret_from_fork+0x7c/0xb0
[<ffffffffffffffff>] 0xffffffffffffffff
So I tried flushing iptables rules and rmmoding netfilter bits:
++++++++++++++++++++-+--------------------+++++++++++----------- 0.179940s
++++++++++++++--+-------------+++++++++++++++++----------------- 0.151988s
++++++++++++++++++++++++++++---+--------------------------+++--- 0.159967s
++++++++++++++++++++++----------------------++++++++++---------- 0.175964s
Expedited:
++-+--++-+-+-+-+-+-+--++-+-+-++-+-+-+--++-+-+-+-+-+-+-+-+-+-+--- 0.079988s
++-+-+-+-+-+-+-+-+-+-+-+--++-+--++-+--+-++-+-+--++-+-+-+-+-+-+-- 0.089347s
++++--+++--++--+-+++++++-+++++--------------++-+-+--++-+-+--++-- 0.081566s
+++++-+++-------++-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+--- 0.089026s
So, much faster. It seems that just loading nf_conntrack_ipv4 (like by
running iptables -t nat -nvL) is enough to slow it way down. But it is
still capable of being fast, as above.
Simon-
^ permalink raw reply
* Re: [PATCH net] tg3: prevent ifup/ifdown during PCI error recovery
From: Prashant @ 2014-08-28 23:28 UTC (permalink / raw)
To: Ivan Vecera, netdev; +Cc: Michael Chan
In-Reply-To: <1409144492-22790-1-git-send-email-ivecera@redhat.com>
Ivan, thanks for the patch. Minor comments.
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
> index 3ac5d23..8d9c774 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -11617,6 +11617,9 @@ static int tg3_open(struct net_device *dev)
> struct tg3 *tp = netdev_priv(dev);
> int err;
>
> + if (tp->pcierr_recovery)
> + return -EAGAIN;
> +
Can have a netdev_err message here indicating the pcie error recovery
that is taking place before returning.
> if (tp->fw_needed) {
> err = tg3_request_firmware(tp);
> if (tg3_asic_rev(tp) == ASIC_REV_57766) {
> @@ -11674,6 +11677,9 @@ static int tg3_close(struct net_device *dev)
> {
> struct tg3 *tp = netdev_priv(dev);
>
> + if (tp->pcierr_recovery)
> + return -EAGAIN;
> +
netdev_err message here too.
> tg3_ptp_fini(tp);
>
> tg3_stop(tp);
> @@ -17561,6 +17567,7 @@ static int tg3_init_one(struct pci_dev *pdev,
> tp->rx_mode = TG3_DEF_RX_MODE;
> tp->tx_mode = TG3_DEF_TX_MODE;
> tp->irq_sync = 1;
> + tp->pcierr_recovery = false;
>
> if (tg3_debug > 0)
> tp->msg_enable = tg3_debug;
> @@ -18071,6 +18078,8 @@ static pci_ers_result_t tg3_io_error_detected(struct pci_dev *pdev,
>
> rtnl_lock();
>
> + tp->pcierr_recovery = true;
> +
> /* We probably don't have netdev yet */
> if (!netdev || !netif_running(netdev))
> goto done;
> @@ -18195,6 +18204,7 @@ static void tg3_io_resume(struct pci_dev *pdev)
> tg3_phy_start(tp);
>
> done:
> + tp->pcierr_recovery = false;
> rtnl_unlock();
> }
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.h b/drivers/net/ethernet/broadcom/tg3.h
> index 461acca..31c9f82 100644
> --- a/drivers/net/ethernet/broadcom/tg3.h
> +++ b/drivers/net/ethernet/broadcom/tg3.h
> @@ -3407,6 +3407,7 @@ struct tg3 {
>
> struct device *hwmon_dev;
> bool link_up;
> + bool pcierr_recovery;
> };
>
> /* Accessor macros for chip and asic attributes
>
^ permalink raw reply
* Re: [PATCH net-next 1/1] r8169: add missing MODULE_FIRMWARE.
From: David Miller @ 2014-08-28 22:22 UTC (permalink / raw)
To: romieu; +Cc: netdev, hau
In-Reply-To: <20140826204038.GA15087@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Tue, 26 Aug 2014 22:40:38 +0200
> From: Francois Romieu <romieu@fr.zoreil.com>
>
> Leftover from 6e1d0b8988188956dac091441c1492a79a342666 ("r8169:add
> support for RTL8168H and RTL8107E").
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Applied, thank you.
^ permalink raw reply
* [PATCH net-next] net: systemport: tell RXCHK if we are using Broadcom tags
From: Florian Fainelli @ 2014-08-28 22:11 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli
When Broadcom tags are enabled, e.g: when interfaced to an Ethernet
switch, make sure that we tell the RXCHK engine that it should be
expecting a 4-bytes Broadcom tag after the Ethernet MAC Source Address.
Use netdev_uses_dsa() to check for that condition since that will tell
us if a switch is attached to our network interface.
Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/broadcom/bcmsysport.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c b/drivers/net/ethernet/broadcom/bcmsysport.c
index 6f4e18644bd4..8f91de169663 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -139,6 +139,15 @@ static int bcm_sysport_set_rx_csum(struct net_device *dev,
else
reg &= ~RXCHK_SKIP_FCS;
+ /* If Broadcom tags are enabled (e.g: using a switch), make
+ * sure we tell the RXCHK hardware to expect a 4-bytes Broadcom
+ * tag after the Ethernet MAC Source Address.
+ */
+ if (netdev_uses_dsa(dev))
+ reg |= RXCHK_BRCM_TAG_EN;
+ else
+ reg &= ~RXCHK_BRCM_TAG_EN;
+
rxchk_writel(priv, reg, RXCHK_CONTROL);
return 0;
--
1.9.1
^ permalink raw reply related
* Re: Concerns regarding PFMEMALLOC handling in __netdev_alloc_skb
From: Eric Dumazet @ 2014-08-28 21:34 UTC (permalink / raw)
To: Shmulik Ladkani; +Cc: Mel Gorman, Neil Brown, David S. Miller, netdev
In-Reply-To: <20140828232350.70684900@halley>
On Thu, 2014-08-28 at 23:23 +0300, Shmulik Ladkani wrote:
> Hi,
>
> From c93bdd0e03 "netvm: allow skb allocation to use PFMEMALLOC reserves":
>
> @@ -366,7 +417,12 @@ struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
> SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>
> if (fragsz <= PAGE_SIZE && !(gfp_mask & (__GFP_WAIT | GFP_DMA))) {
> - void *data = netdev_alloc_frag(fragsz);
> + void *data;
> +
> + if (sk_memalloc_socks())
> + gfp_mask |= __GFP_MEMALLOC;
> +
> + data = __netdev_alloc_frag(fragsz, gfp_mask);
>
> if (likely(data)) {
> skb = build_skb(data, fragsz);
> if (unlikely(!skb))
> put_page(virt_to_head_page(data));
> }
> } else {
> - skb = __alloc_skb(length + NET_SKB_PAD, gfp_mask, 0, NUMA_NO_NODE);
> + skb = __alloc_skb(length + NET_SKB_PAD, gfp_mask,
> + SKB_ALLOC_RX, NUMA_NO_NODE);
> }
>
> In the 'else' part, SKB_ALLOC_RX is provided to '__alloc_skb()'.
> Thus '__alloc_skb()' may attempt using the PFMEMALLOC reserve in case
> 'sk_memalloc_socks()' is true - and 'skb->pfmemalloc' will be set
> accordingly. Good.
>
> However, in the 'if' part, in case 'sk_memalloc_socks()' is true,
> __GFP_MEMALLOC is passed to '__netdev_alloc_frag()'.
>
> There are two possible issues here:
>
> 1. '__netdev_alloc_frag()' might not honour __GFP_MEMALLOC in case the
> frag fits into current netdev_alloc_cache.frag
>
> 2. Even if 'nc->frag.page' gets allocated/refilled, and __GFP_MEMALLOC
> is passed to 'alloc_pages()' - in case the new page is from the
> PFMEMALLOC reserve, that notion is not propagated to back to
> skb->pfmemalloc.
>
> Are these of any concern?
This was discussed few days ago.
http://www.spinics.net/lists/netdev/msg293334.html
http://www.spinics.net/lists/netdev/msg293336.html
You should sync with Govindarajulu Varadarajan to cook a proper patch.
^ permalink raw reply
* Re: [net-next 00/11][pull request] Intel Wired LAN Driver Updates 2014-08-27
From: David Miller @ 2014-08-28 21:19 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann
In-Reply-To: <1409131606-15011-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 27 Aug 2014 02:26:35 -0700
> This series contains updates to i40e and i40evf.
Pulled, thanks Jeff.
^ 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