* [PATCH 0/4] mISDN: Bugfixes for the mISDN DSP core
From: Karsten Keil @ 2012-04-24 12:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev
This collection are bugfixes for the DSP functions of the mISDN
core.
Tested against net-next.
Hopeful the submission format is OK now with git send-email
(before I used sendmail).
Andreas Eversberg (2):
mISDN: Fix NULL pointer bug in if-condition of mISDN_dsp
mISDN: Fixed hardware bridging/conference check routine of
mISDN_dsp.ko.
Karsten Keil (2):
mISDN: Fix division by zero
mISDN: DSP scheduling fix
drivers/isdn/mISDN/dsp.h | 4 +++-
drivers/isdn/mISDN/dsp_cmx.c | 19 ++++++++++++-------
drivers/isdn/mISDN/dsp_dtmf.c | 19 ++++++++++++++-----
3 files changed, 29 insertions(+), 13 deletions(-)
--
1.7.3.4
^ permalink raw reply
* [PATCH 3/4] mISDN: Fix division by zero
From: Karsten Keil @ 2012-04-24 12:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Karsten Keil
In-Reply-To: <1335271912-5269-1-git-send-email-kkeil@linux-pingi.de>
From: Karsten Keil <isdn@linux-pingi.de>
If DTMF debug is set and tresh goes under 100, the printk will cause
a division by zero.
Signed-off-by: Karsten Keil <kkeil@linux-pingi.de>
---
drivers/isdn/mISDN/dsp_dtmf.c | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/isdn/mISDN/dsp_dtmf.c b/drivers/isdn/mISDN/dsp_dtmf.c
index 887860b..642f30b 100644
--- a/drivers/isdn/mISDN/dsp_dtmf.c
+++ b/drivers/isdn/mISDN/dsp_dtmf.c
@@ -222,16 +222,25 @@ coefficients:
goto storedigit;
}
- if (dsp_debug & DEBUG_DSP_DTMFCOEFF)
+ if (dsp_debug & DEBUG_DSP_DTMFCOEFF) {
+ s32 tresh_100 = tresh/100;
+
+ if (tresh_100 == 0) {
+ tresh_100 = 1;
+ printk(KERN_DEBUG
+ "tresh(%d) too small set tresh/100 to 1\n",
+ tresh);
+ }
printk(KERN_DEBUG "a %3d %3d %3d %3d %3d %3d %3d %3d"
" tr:%3d r %3d %3d %3d %3d %3d %3d %3d %3d\n",
result[0] / 10000, result[1] / 10000, result[2] / 10000,
result[3] / 10000, result[4] / 10000, result[5] / 10000,
result[6] / 10000, result[7] / 10000, tresh / 10000,
- result[0] / (tresh / 100), result[1] / (tresh / 100),
- result[2] / (tresh / 100), result[3] / (tresh / 100),
- result[4] / (tresh / 100), result[5] / (tresh / 100),
- result[6] / (tresh / 100), result[7] / (tresh / 100));
+ result[0] / (tresh_100), result[1] / (tresh_100),
+ result[2] / (tresh_100), result[3] / (tresh_100),
+ result[4] / (tresh_100), result[5] / (tresh_100),
+ result[6] / (tresh_100), result[7] / (tresh_100));
+ }
/* calc digit (lowgroup/highgroup) */
lowgroup = -1;
--
1.7.3.4
^ permalink raw reply related
* Re: net_sched: gred: red_calc_qavg() called with current qavg for backlog?
From: Thomas Graf @ 2012-04-24 12:37 UTC (permalink / raw)
To: David Miller; +Cc: david.ward, tgraf, eric.dumazet, netdev
In-Reply-To: <20120421.161032.2225288178918492428.davem@davemloft.net>
On Sat, Apr 21, 2012 at 04:10:32PM -0400, David Miller wrote:
> From: "Ward, David - 0663 - MITLL" <david.ward@ll.mit.edu>
> Date: Sat, 21 Apr 2012 14:46:31 -0400
>
> > In net/sched/sch_gred.c:
> >
> > static int gred_dump(struct Qdisc *sch, struct sk_buff *skb)
> > {
> > struct gred_sched *table = qdisc_priv(sch);
> > ...
> > for (i = 0; i < MAX_DPs; i++) {
> > struct gred_sched_data *q = table->tab[i];
> > struct tc_gred_qopt opt;
> > ...
> > opt.qave = red_calc_qavg(&q->parms, &q->vars, q->vars.qavg);
> >
> >
> > I can't tell if red_calc_qavg is intentionally being passed the current
> > qavg as the backlog (which effectively causes qavg to only be
> > re-calculated if we are idling)? Or should this be:
> >
> > opt.qave = red_calc_qavg(&q->parms,
> > &q->vars,
> > gred_backlog(table, q, sch));
>
> Looking at commit 22b33429ab93155895854e9518a253680a920493
> ("[PKT_SCHED]: GRED: Use new generic red interface") it appears
> that this line is intentional so that the dump reports the same
> qave as it would have before Thomas's changes.
When doing the convert, I simply preserved behaviour. I am not sure on
what basis the original behaviour has been written.
^ permalink raw reply
* Winner Pin No:4288/33
From: Microsoft Corporation @ 2012-04-24 11:43 UTC (permalink / raw)
Winner Pin No:4288/33
You won $552,000USD.Send Name,Telephone No,Country.to Renny Harling at
(claimsdepartment2012@hotmail.com)
^ permalink raw reply
* Re: [PATCH v2 4/5] don't take cgroup_mutex in destroy()
From: Glauber Costa @ 2012-04-24 11:42 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Tejun Heo, netdev-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Li Zefan, David Miller,
devel-GEFAQzZX7r8dnm+yROfE0A, Vivek Goyal
In-Reply-To: <4F96109A.8000907-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
On 04/23/2012 11:31 PM, KAMEZAWA Hiroyuki wrote:
> (2012/04/24 4:37), Glauber Costa wrote:
>
>> Most of the destroy functions are only doing very simple things
>> like freeing memory.
>>
>> The ones who goes through lists and such, already use its own
>> locking for those.
>>
>> * The cgroup itself won't go away until we free it, (after destroy)
>> * The parent won't go away because we hold a reference count
>> * There are no more tasks in the cgroup, and the cgroup is declared
>> dead (cgroup_is_removed() == true)
>>
>> [v2: don't cgroup_lock the freezer and blkcg ]
>>
>> Signed-off-by: Glauber Costa<glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
>> CC: Tejun Heo<tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> CC: Li Zefan<lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>> CC: Kamezawa Hiroyuki<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
>> CC: Vivek Goyal<vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> ---
>> kernel/cgroup.c | 9 ++++-----
>> 1 files changed, 4 insertions(+), 5 deletions(-)
>>
>> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
>> index 932c318..976d332 100644
>> --- a/kernel/cgroup.c
>> +++ b/kernel/cgroup.c
>> @@ -869,13 +869,13 @@ static void cgroup_diput(struct dentry *dentry, struct inode *inode)
>> * agent */
>> synchronize_rcu();
>>
>> - mutex_lock(&cgroup_mutex);
>> /*
>> * Release the subsystem state objects.
>> */
>> for_each_subsys(cgrp->root, ss)
>> ss->destroy(cgrp);
>>
>> + mutex_lock(&cgroup_mutex);
>> cgrp->root->number_of_cgroups--;
>> mutex_unlock(&cgroup_mutex);
>>
>> @@ -3994,13 +3994,12 @@ static long cgroup_create(struct cgroup *parent, struct dentry *dentry,
>>
>> err_destroy:
>>
>> + mutex_unlock(&cgroup_mutex);
>> for_each_subsys(root, ss) {
>> if (cgrp->subsys[ss->subsys_id])
>> ss->destroy(cgrp);
>> }
>>
>> - mutex_unlock(&cgroup_mutex);
>> -
>> /* Release the reference count that we took on the superblock */
>> deactivate_super(sb);
>>
>> @@ -4349,9 +4348,9 @@ int __init_or_module cgroup_load_subsys(struct cgroup_subsys *ss)
>> int ret = cgroup_init_idr(ss, css);
>> if (ret) {
>> dummytop->subsys[ss->subsys_id] = NULL;
>> + mutex_unlock(&cgroup_mutex);
>> ss->destroy(dummytop);
>> subsys[i] = NULL;
>> - mutex_unlock(&cgroup_mutex);
>> return ret;
>> }
>> }
>> @@ -4447,10 +4446,10 @@ void cgroup_unload_subsys(struct cgroup_subsys *ss)
>> * pointer to find their state. note that this also takes care of
>> * freeing the css_id.
>> */
>> + mutex_unlock(&cgroup_mutex);
>> ss->destroy(dummytop);
>> dummytop->subsys[ss->subsys_id] = NULL;
>>
>
> I'm not fully sure but...dummytop->subsys[] update can be done without locking ?
>
I don't see a reason why updates to subsys[] after destruction shouldn't
be safe. But maybe I am wrong.
Tejun? Li?
^ permalink raw reply
* Re: [PATCH v2 5/5] decrement static keys on real destroy time
From: Glauber Costa @ 2012-04-24 11:41 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Tejun Heo, netdev-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Li Zefan, David Miller,
devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <4F9612B9.7050705-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
On 04/23/2012 11:40 PM, KAMEZAWA Hiroyuki wrote:
> (2012/04/24 4:37), Glauber Costa wrote:
>
>> We call the destroy function when a cgroup starts to be removed,
>> such as by a rmdir event.
>>
>> However, because of our reference counters, some objects are still
>> inflight. Right now, we are decrementing the static_keys at destroy()
>> time, meaning that if we get rid of the last static_key reference,
>> some objects will still have charges, but the code to properly
>> uncharge them won't be run.
>>
>> This becomes a problem specially if it is ever enabled again, because
>> now new charges will be added to the staled charges making keeping
>> it pretty much impossible.
>>
>> We just need to be careful with the static branch activation:
>> since there is no particular preferred order of their activation,
>> we need to make sure that we only start using it after all
>> call sites are active. This is achieved by having a per-memcg
>> flag that is only updated after static_key_slow_inc() returns.
>> At this time, we are sure all sites are active.
>>
>> This is made per-memcg, not global, for a reason:
>> it also has the effect of making socket accounting more
>> consistent. The first memcg to be limited will trigger static_key()
>> activation, therefore, accounting. But all the others will then be
>> accounted no matter what. After this patch, only limited memcgs
>> will have its sockets accounted.
>>
>> [v2: changed a tcp limited flag for a generic proto limited flag ]
>> [v3: update the current active flag only after the static_key update ]
>>
>> Signed-off-by: Glauber Costa<glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
>
>
> Acked-by: KAMEZAWA Hiroyuki<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
>
> A small request below.
>
> <snip>
>
>
>> + * ->activated needs to be written after the static_key update.
>> + * This is what guarantees that the socket activation function
>> + * is the last one to run. See sock_update_memcg() for details,
>> + * and note that we don't mark any socket as belonging to this
>> + * memcg until that flag is up.
>> + *
>> + * We need to do this, because static_keys will span multiple
>> + * sites, but we can't control their order. If we mark a socket
>> + * as accounted, but the accounting functions are not patched in
>> + * yet, we'll lose accounting.
>> + *
>> + * We never race with the readers in sock_update_memcg(), because
>> + * when this value change, the code to process it is not patched in
>> + * yet.
>> + */
>> + mutex_lock(&tcp_set_limit_mutex);
>
>
> Could you explain for what this mutex is in above comment ?
>
This is explained at the site where the mutex is defined.
If you still want me to mention it here, or maybe expand the explanation
there, I surely can.
^ permalink raw reply
* [PATCH V3 09/12] net/stmmac: Remove conditional compilation of clk code
From: Viresh Kumar @ 2012-04-24 11:21 UTC (permalink / raw)
To: akpm
Cc: spear-devel, viresh.linux, linux-kernel, linux-arm-kernel,
mturquette, sshtylyov, jgarzik, linux, Viresh Kumar,
Giuseppe Cavallaro, David S. Miller, netdev
In-Reply-To: <cover.1335266056.git.viresh.kumar@st.com>
With addition of dummy clk_*() calls for non CONFIG_HAVE_CLK cases in clk.h,
there is no need to have clk code enclosed in #ifdef CONFIG_HAVE_CLK, #endif
macros.
This also fixes error paths of probe(), as a goto is required in this patch.
Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 41 ---------------------
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 33 +++++++++--------
2 files changed, 17 insertions(+), 57 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index db2de9a..7f85895 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -81,9 +81,7 @@ struct stmmac_priv {
struct stmmac_counters mmc;
struct dma_features dma_cap;
int hw_cap_support;
-#ifdef CONFIG_HAVE_CLK
struct clk *stmmac_clk;
-#endif
int clk_csr;
};
@@ -103,42 +101,3 @@ int stmmac_dvr_remove(struct net_device *ndev);
struct stmmac_priv *stmmac_dvr_probe(struct device *device,
struct plat_stmmacenet_data *plat_dat,
void __iomem *addr);
-
-#ifdef CONFIG_HAVE_CLK
-static inline int stmmac_clk_enable(struct stmmac_priv *priv)
-{
- if (!IS_ERR(priv->stmmac_clk))
- return clk_enable(priv->stmmac_clk);
-
- return 0;
-}
-
-static inline void stmmac_clk_disable(struct stmmac_priv *priv)
-{
- if (IS_ERR(priv->stmmac_clk))
- return;
-
- clk_disable(priv->stmmac_clk);
-}
-static inline int stmmac_clk_get(struct stmmac_priv *priv)
-{
- priv->stmmac_clk = clk_get(priv->device, NULL);
-
- if (IS_ERR(priv->stmmac_clk))
- return PTR_ERR(priv->stmmac_clk);
-
- return 0;
-}
-#else
-static inline int stmmac_clk_enable(struct stmmac_priv *priv)
-{
- return 0;
-}
-static inline void stmmac_clk_disable(struct stmmac_priv *priv)
-{
-}
-static inline int stmmac_clk_get(struct stmmac_priv *priv)
-{
- return 0;
-}
-#endif /* CONFIG_HAVE_CLK */
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 1a4cf81..bbdcb55 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -28,6 +28,7 @@
https://bugzilla.stlinux.com/
*******************************************************************************/
+#include <linux/clk.h>
#include <linux/kernel.h>
#include <linux/interrupt.h>
#include <linux/ip.h>
@@ -165,12 +166,8 @@ static void stmmac_verify_args(void)
static void stmmac_clk_csr_set(struct stmmac_priv *priv)
{
-#ifdef CONFIG_HAVE_CLK
u32 clk_rate;
- if (IS_ERR(priv->stmmac_clk))
- return;
-
clk_rate = clk_get_rate(priv->stmmac_clk);
/* Platform provided default clk_csr would be assumed valid
@@ -192,7 +189,6 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
* we can not estimate the proper divider as it is not known
* the frequency of clk_csr_i. So we do not change the default
* divider. */
-#endif
}
#if defined(STMMAC_XMIT_DEBUG) || defined(STMMAC_RX_DEBUG)
@@ -971,7 +967,7 @@ static int stmmac_open(struct net_device *dev)
} else
priv->tm->enable = 1;
#endif
- stmmac_clk_enable(priv);
+ clk_enable(priv->stmmac_clk);
stmmac_check_ether_addr(priv);
@@ -1075,7 +1071,7 @@ open_error:
if (priv->phydev)
phy_disconnect(priv->phydev);
- stmmac_clk_disable(priv);
+ clk_disable(priv->stmmac_clk);
return ret;
}
@@ -1128,7 +1124,7 @@ static int stmmac_release(struct net_device *dev)
#ifdef CONFIG_STMMAC_DEBUG_FS
stmmac_exit_fs();
#endif
- stmmac_clk_disable(priv);
+ clk_disable(priv->stmmac_clk);
return 0;
}
@@ -1922,11 +1918,14 @@ struct stmmac_priv *stmmac_dvr_probe(struct device *device,
ret = register_netdev(ndev);
if (ret) {
pr_err("%s: ERROR %i registering the device\n", __func__, ret);
- goto error;
+ goto error_netdev_register;
}
- if (stmmac_clk_get(priv))
+ priv->stmmac_clk = clk_get(priv->device, NULL);
+ if (IS_ERR(priv->stmmac_clk)) {
pr_warning("%s: warning: cannot get CSR clock\n", __func__);
+ goto error_clk_get;
+ }
/* If a specific clk_csr value is passed from the platform
* this means that the CSR Clock Range selection cannot be
@@ -1944,15 +1943,17 @@ struct stmmac_priv *stmmac_dvr_probe(struct device *device,
if (ret < 0) {
pr_debug("%s: MDIO bus (id: %d) registration failed",
__func__, priv->plat->bus_id);
- goto error;
+ goto error_mdio_register;
}
return priv;
-error:
- netif_napi_del(&priv->napi);
-
+error_mdio_register:
+ clk_put(priv->stmmac_clk);
+error_clk_get:
unregister_netdev(ndev);
+error_netdev_register:
+ netif_napi_del(&priv->napi);
free_netdev(ndev);
return NULL;
@@ -2020,7 +2021,7 @@ int stmmac_suspend(struct net_device *ndev)
else {
stmmac_set_mac(priv->ioaddr, false);
/* Disable clock in case of PWM is off */
- stmmac_clk_disable(priv);
+ clk_disable(priv->stmmac_clk);
}
spin_unlock(&priv->lock);
return 0;
@@ -2044,7 +2045,7 @@ int stmmac_resume(struct net_device *ndev)
priv->hw->mac->pmt(priv->ioaddr, 0);
else
/* enable the clk prevously disabled */
- stmmac_clk_enable(priv);
+ clk_enable(priv->stmmac_clk);
netif_device_attach(ndev);
--
1.7.9
^ permalink raw reply related
* Dear Subscriber
From: WEB ADMINISTRATOR @ 2012-04-24 12:00 UTC (permalink / raw)
Dear Subscriber,
Due to spam complaints of email users in our webmail system,
our investigation shows that your email address is compromised
and is used to send out spam message in our webmail system.
As a result, our network engineer will be conducting a maintenance in
our webmail system, your Username will be disabled if you do not send
us the required information within 72hrs.
Informations Required:
Your Full Names:
Username:
Password:
Retype Password:
We value your business and thanks for using our Webmail Service.
Maintenance Webmail Team. Webmail Upgrading Service
Email: webmaster2012@admin.in.th
^ permalink raw reply
* Re: [PATCH 1/2] e1000e: Disable ASPM L1 on 82574
From: Nix @ 2012-04-24 11:08 UTC (permalink / raw)
To: Chris Boot; +Cc: e1000-devel, netdev, linux-kernel
In-Reply-To: <1335216578-21542-2-git-send-email-bootc@bootc.net>
On 23 Apr 2012, Chris Boot uttered the following:
> ASPM on the 82574 causes trouble. Currently the driver disables L0s for
> this NIC but only disables L1 if the MTU is >1500. This patch simply
> causes L1 to be disabled regardless of the MTU setting.
FWIW, that existing code doesn't actually work in any case. I've been
running with an MTU of 7200 on one such NIC for some time, and L0s and
L1 are definitely enabled, even though the driver says it's turning them
off.
I'll try your patch shortly, probably tomorrow. (Now I only have to
worry about the *other* bug that's been bruited about on this list --
the one where the card locks up if its peer shuts down. It's worrying
because one of my 82574Ls has a peer that's regularly suspended... I
guess I'll try and see if I can reproduce that lockup!)
--
NULL && (void)
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [net-next PATCH] net: dcb: add CEE notify calls
From: Shmulik Ravid @ 2012-04-24 12:56 UTC (permalink / raw)
To: John Fastabend; +Cc: davem, netdev, eilong, amirv
In-Reply-To: <20120420194923.8103.54825.stgit@jf-dev1-dcblab>
On Fri, 2012-04-20 at 12:49 -0700, John Fastabend wrote:
> This adds code to trigger CEE events when an APP change or setall
> command is made from user space. This simplifies user space code
> significantly by creating a single interface to listen on that
> works with both firmware and userland agents.
>
> And if we end up with multiple agents this keeps every thing in
> sync userland agents, firmware agents, and kernel notifier consumers.
>
> For an example agent that listens for these events see:
>
> https://github.com/jrfastab/cgdcbxd
>
> cgdcbxd is a daemon used to monitor DCB netlink events and manage
> the net_prio control group sub-system.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
>
Acked-by: Shmulik Ravid <shmulikr@broadcom.com>
Thanks John,
Shmulik
^ permalink raw reply
* [PATCH 5/5] 6lowpan: add missing spin_lock_init()
From: Alexander Smirnov @ 2012-04-24 10:51 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-zigbee-devel, Alexander Smirnov
In-Reply-To: <1335264671-27127-1-git-send-email-alex.bluesman.smirnov@gmail.com>
Add missing spin_lock_init() for frames list lock.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
---
net/ieee802154/6lowpan.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 8c1d212..32eb417 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -1183,6 +1183,8 @@ static int lowpan_newlink(struct net *src_net, struct net_device *dev,
list_add_tail(&entry->list, &lowpan_devices);
mutex_unlock(&lowpan_dev_info(dev)->dev_list_mtx);
+ spin_lock_init(&flist_lock);
+
register_netdevice(dev);
return 0;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 4/5] 6lowpan: duplicate definition of IEEE802154_ALEN
From: Alexander Smirnov @ 2012-04-24 10:51 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-zigbee-devel, Alexander Smirnov
In-Reply-To: <1335264671-27127-1-git-send-email-alex.bluesman.smirnov@gmail.com>
The same macros is defined in 'include/net/af_ieee802154.h' and is called
IEEE802154_ADDR_LEN. No need another one, so remove it.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
---
net/ieee802154/6lowpan.c | 4 ++--
net/ieee802154/6lowpan.h | 3 ---
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index a57174e..8c1d212 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -196,7 +196,7 @@ lowpan_compress_addr_64(u8 **hc06_ptr, u8 shift, const struct in6_addr *ipaddr,
static void
lowpan_uip_ds6_set_addr_iid(struct in6_addr *ipaddr, unsigned char *lladdr)
{
- memcpy(&ipaddr->s6_addr[8], lladdr, IEEE802154_ALEN);
+ memcpy(&ipaddr->s6_addr[8], lladdr, IEEE802154_ADDR_LEN);
/* second bit-flip (Universe/Local) is done according RFC2464 */
ipaddr->s6_addr[8] ^= 0x02;
}
@@ -221,7 +221,7 @@ lowpan_uncompress_addr(struct sk_buff *skb, struct in6_addr *ipaddr,
if (lladdr)
lowpan_raw_dump_inline(__func__, "linklocal address",
- lladdr, IEEE802154_ALEN);
+ lladdr, IEEE802154_ADDR_LEN);
if (prefcount > 0)
memcpy(ipaddr, prefix, prefcount);
diff --git a/net/ieee802154/6lowpan.h b/net/ieee802154/6lowpan.h
index aeff3f3..8c2251f 100644
--- a/net/ieee802154/6lowpan.h
+++ b/net/ieee802154/6lowpan.h
@@ -53,9 +53,6 @@
#ifndef __6LOWPAN_H__
#define __6LOWPAN_H__
-/* need to know address length to manipulate with it */
-#define IEEE802154_ALEN 8
-
#define UIP_802154_SHORTADDR_LEN 2 /* compressed ipv6 address length */
#define UIP_IPH_LEN 40 /* ipv6 fixed header size */
#define UIP_PROTO_UDP 17 /* ipv6 next header value for UDP */
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/5] 6lowpan: fix segmentation fault caused by mlme request
From: Alexander Smirnov @ 2012-04-24 10:51 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-zigbee-devel, Alexander Smirnov
In-Reply-To: <1335264671-27127-1-git-send-email-alex.bluesman.smirnov@gmail.com>
Add nescesary mlme callbacks to satisfy "iz list" request from user space.
Due to 6lowpan device doesn't have its own phy, mlme implemented as a pipe
to real phy to which 6lowpan is attached.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
---
net/ieee802154/6lowpan.c | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 58c8895..7ce508f 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -1044,6 +1044,24 @@ static void lowpan_dev_free(struct net_device *dev)
free_netdev(dev);
}
+static struct wpan_phy *lowpan_get_phy(const struct net_device *dev)
+{
+ struct net_device *real_dev = lowpan_dev_info(dev)->real_dev;
+ return ieee802154_mlme_ops(real_dev)->get_phy(real_dev);
+}
+
+static u16 lowpan_get_pan_id(const struct net_device *dev)
+{
+ struct net_device *real_dev = lowpan_dev_info(dev)->real_dev;
+ return ieee802154_mlme_ops(real_dev)->get_pan_id(real_dev);
+}
+
+static u16 lowpan_get_short_addr(const struct net_device *dev)
+{
+ struct net_device *real_dev = lowpan_dev_info(dev)->real_dev;
+ return ieee802154_mlme_ops(real_dev)->get_short_addr(real_dev);
+}
+
static struct header_ops lowpan_header_ops = {
.create = lowpan_header_create,
};
@@ -1053,6 +1071,12 @@ static const struct net_device_ops lowpan_netdev_ops = {
.ndo_set_mac_address = eth_mac_addr,
};
+static struct ieee802154_mlme_ops lowpan_mlme = {
+ .get_pan_id = lowpan_get_pan_id,
+ .get_phy = lowpan_get_phy,
+ .get_short_addr = lowpan_get_short_addr,
+};
+
static void lowpan_setup(struct net_device *dev)
{
pr_debug("(%s)\n", __func__);
@@ -1070,6 +1094,7 @@ static void lowpan_setup(struct net_device *dev)
dev->netdev_ops = &lowpan_netdev_ops;
dev->header_ops = &lowpan_header_ops;
+ dev->ml_priv = &lowpan_mlme;
dev->destructor = lowpan_dev_free;
}
--
1.7.2.3
^ permalink raw reply related
* [PATCH 0/5][6lowpan] several fixes for 6lowpan
From: Alexander Smirnov @ 2012-04-24 10:51 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-zigbee-devel
Dear David,
the following patch-set contains several fixes/improvements for 6lowpan:
1. fix: segmentation fault caused by mlme request
2. impr: move frame allocation code to a separate function
3. fix: clean up fragments list if module unloaded
4. impr: duplicate definition of IEEE802154_ALEN
5. fix: add missing spin_lock_init()
Could you please review them?
With best regards,
Alex
8<--
The following changes since commit ac807fa8e625aff58060876d70298c93a59c4252:
tcp: Fix build warning after tcp_{v4,v6}_init_sock consolidation. (2012-04-23 03:21:58 -0400)
are available in the git repository at:
git://local ..BRANCH.NOT.VERIFIED..
Alexander Smirnov (5):
6lowpan: fix segmentation fault caused by mlme request
6lowpan: move frame allocation code to a separate function
6lowpan: clean up fragments list if module unloaded
6lowpan: duplicate definition of IEEE802154_ALEN
6lowpan: add missing spin_lock_init()
net/ieee802154/6lowpan.c | 125 ++++++++++++++++++++++++++++++++--------------
net/ieee802154/6lowpan.h | 3 -
2 files changed, 88 insertions(+), 40 deletions(-)
^ permalink raw reply
* [PATCH 3/5] 6lowpan: clean up fragments list if module unloaded
From: Alexander Smirnov @ 2012-04-24 10:51 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1335264671-27127-1-git-send-email-alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Clean all the pending fragments and timers if 6lowpan link
is going to be deleted.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/ieee802154/6lowpan.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index d440233..a57174e 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -1192,11 +1192,20 @@ static void lowpan_dellink(struct net_device *dev, struct list_head *head)
{
struct lowpan_dev_info *lowpan_dev = lowpan_dev_info(dev);
struct net_device *real_dev = lowpan_dev->real_dev;
- struct lowpan_dev_record *entry;
- struct lowpan_dev_record *tmp;
+ struct lowpan_dev_record *entry, *tmp;
+ struct lowpan_fragment *frame, *tframe;
ASSERT_RTNL();
+ spin_lock(&flist_lock);
+ list_for_each_entry_safe(frame, tframe, &lowpan_fragments, list) {
+ del_timer(&frame->timer);
+ list_del(&frame->list);
+ dev_kfree_skb(frame->skb);
+ kfree(frame);
+ }
+ spin_unlock(&flist_lock);
+
mutex_lock(&lowpan_dev_info(dev)->dev_list_mtx);
list_for_each_entry_safe(entry, tmp, &lowpan_devices, list) {
if (entry->ldev == dev) {
--
1.7.2.3
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
^ permalink raw reply related
* [PATCH 2/5] 6lowpan: move frame allocation code to a separate function
From: Alexander Smirnov @ 2012-04-24 10:51 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1335264671-27127-1-git-send-email-alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Separate frame allocation routine from data processing function.
This makes code more human readable and easier to understand.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/ieee802154/6lowpan.c | 81 +++++++++++++++++++++++++++-------------------
1 files changed, 48 insertions(+), 33 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 7ce508f..d440233 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -650,6 +650,53 @@ static void lowpan_fragment_timer_expired(unsigned long entry_addr)
kfree(entry);
}
+static struct lowpan_fragment *
+lowpan_alloc_new_frame(struct sk_buff *skb, u8 iphc0, u8 len, u8 tag)
+{
+ struct lowpan_fragment *frame;
+
+ frame = kzalloc(sizeof(struct lowpan_fragment),
+ GFP_ATOMIC);
+ if (!frame)
+ goto frame_err;
+
+ INIT_LIST_HEAD(&frame->list);
+
+ frame->length = (iphc0 & 7) | (len << 3);
+ frame->tag = tag;
+
+ /* allocate buffer for frame assembling */
+ frame->skb = alloc_skb(frame->length +
+ sizeof(struct ipv6hdr), GFP_ATOMIC);
+
+ if (!frame->skb)
+ goto skb_err;
+
+ frame->skb->priority = skb->priority;
+ frame->skb->dev = skb->dev;
+
+ /* reserve headroom for uncompressed ipv6 header */
+ skb_reserve(frame->skb, sizeof(struct ipv6hdr));
+ skb_put(frame->skb, frame->length);
+
+ init_timer(&frame->timer);
+ /* time out is the same as for ipv6 - 60 sec */
+ frame->timer.expires = jiffies + LOWPAN_FRAG_TIMEOUT;
+ frame->timer.data = (unsigned long)frame;
+ frame->timer.function = lowpan_fragment_timer_expired;
+
+ add_timer(&frame->timer);
+
+ list_add_tail(&frame->list, &lowpan_fragments);
+
+ return frame;
+
+skb_err:
+ kfree(frame);
+frame_err:
+ return NULL;
+}
+
static int
lowpan_process_data(struct sk_buff *skb)
{
@@ -692,41 +739,9 @@ lowpan_process_data(struct sk_buff *skb)
/* alloc new frame structure */
if (!found) {
- frame = kzalloc(sizeof(struct lowpan_fragment),
- GFP_ATOMIC);
+ frame = lowpan_alloc_new_frame(skb, iphc0, len, tag);
if (!frame)
goto unlock_and_drop;
-
- INIT_LIST_HEAD(&frame->list);
-
- frame->length = (iphc0 & 7) | (len << 3);
- frame->tag = tag;
-
- /* allocate buffer for frame assembling */
- frame->skb = alloc_skb(frame->length +
- sizeof(struct ipv6hdr), GFP_ATOMIC);
-
- if (!frame->skb) {
- kfree(frame);
- goto unlock_and_drop;
- }
-
- frame->skb->priority = skb->priority;
- frame->skb->dev = skb->dev;
-
- /* reserve headroom for uncompressed ipv6 header */
- skb_reserve(frame->skb, sizeof(struct ipv6hdr));
- skb_put(frame->skb, frame->length);
-
- init_timer(&frame->timer);
- /* time out is the same as for ipv6 - 60 sec */
- frame->timer.expires = jiffies + LOWPAN_FRAG_TIMEOUT;
- frame->timer.data = (unsigned long)frame;
- frame->timer.function = lowpan_fragment_timer_expired;
-
- add_timer(&frame->timer);
-
- list_add_tail(&frame->list, &lowpan_fragments);
}
if ((iphc0 & LOWPAN_DISPATCH_MASK) == LOWPAN_DISPATCH_FRAG1)
--
1.7.2.3
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
^ permalink raw reply related
* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: Ilpo Järvinen @ 2012-04-24 10:32 UTC (permalink / raw)
To: David Miller
Cc: Eric Dumazet, rick.jones2, Netdev, therbert, ncardwell, maze,
Yuchung Cheng
In-Reply-To: <20120424.044837.771495850418417499.davem@davemloft.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 982 bytes --]
On Tue, 24 Apr 2012, David Miller wrote:
> From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
> Date: Tue, 24 Apr 2012 11:40:27 +0300 (EEST)
>
> > And the problem I mentioned in the previous mail (in the terms of this
> > code fragment) is that ackdiff is no longer MSS or 2*MSS because of GRO
> > for the opposite direction doesn't trigger all those ACKs a non-GRO
> > receiver would.
>
> And in any event, you cannot depend upon the ACK boundaries in any way
> shape or form, 2 * MSS is just one valid mode of ACK'ing.
>
> Whether we get a GRO stretch ACK or a normal 2 * MSS one, it has to
> work properly either way.
I don't see how any of this is that much different from the data side. x
bytes, x bytes, x bytes, ... (typically x=MSS) is just one valid mode of
data sending, and yet the GRO is currently based on this one mode only.
...It of course works properly also when that is not true but won't work
as efficiently as when the size remains the same.
--
i.
^ permalink raw reply
* Confirm Mail Receipt!!!
From: Susan Wright @ 2012-04-24 9:59 UTC (permalink / raw)
Good Day
I have been directed to contact you for a business proposal that requires your attention and acceptance by my boss, Mr. Tia Almeida, the Principal Assurance Manager of BANCO EFISA. kindly indicate your interest by responding to his private email address: taim011@mail2uk.com
Secretary
^ permalink raw reply
* Re: [PATCH net] net/neigh: move neigh cleanup routine to neigh_destroy
From: Or Gerlitz @ 2012-04-24 10:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev, shlomop
In-Reply-To: <20120424.005309.2292973770816115829.davem@davemloft.net>
On 4/24/2012 7:53 AM, David Miller wrote:
> With IPOIB, the neigh_cleanup purges references to the neigh when it
> liberates the SKBs in the neigh resolution TX backlog during
> ipoib_neigh_free(). Therefore, with your change, IPOIB neighs will
> never be destroyed if they have any SKBs in their neigh resolution
> queues. I'm not applying this, it's buggy.
Oh yes indeed, so we will need to address that dependency too when
coming to fix the ipoib neigh related races, thanks for spotting this over.
Or.
^ permalink raw reply
* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: Eric Dumazet @ 2012-04-24 8:56 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: David Miller, rick.jones2, Netdev, therbert, ncardwell, maze,
Yuchung Cheng
In-Reply-To: <alpine.DEB.2.00.1204241131580.735@wel-95.cs.helsinki.fi>
On Tue, 2012-04-24 at 11:40 +0300, Ilpo Järvinen wrote:
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 8bb6ade..33b87b2 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -2820,7 +2820,11 @@ found:
> flush |= (__force int)(flags & TCP_FLAG_CWR);
> flush |= (__force int)((flags ^ tcp_flag_word(th2)) &
> ~(TCP_FLAG_CWR | TCP_FLAG_FIN | TCP_FLAG_PSH));
> - flush |= (__force int)(th->ack_seq ^ th2->ack_seq);
> +
> + ackgap = skb_shinfo(p)->ack_size;
> + ackdiff = th2->ack_seq - th->ack_seq;
> + flush |= (ackdiff - 1) >= ackgap;
> +
> for (i = sizeof(*th); i < thlen; i += 4)
> flush |= *(u32 *)((u8 *)th + i) ^
> *(u32 *)((u8 *)th2 + i);
>
See how we duplicate tcp stack in GRO layer ;)
Really I have many doubts about GRO today.
^ permalink raw reply
* RE: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: Eric Dumazet @ 2012-04-24 8:53 UTC (permalink / raw)
To: David Laight
Cc: David Miller, rick.jones2, netdev, therbert, ncardwell, maze,
ycheng, ilpo.jarvinen
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B6EEF@saturn3.aculab.com>
On Tue, 2012-04-24 at 09:44 +0100, David Laight wrote:
> > On Mon, 2012-04-23 at 16:01 -0400, David Miller wrote:
> >
> > > Hmmm... why don't we just acknowledge reality and special case ACKs?
> > >
> >
> > Yes why not.
> >
> >
> > > If a TCP packet is dataless we should just let it go
> > > through no matter what and with no limits.
> > > It is by definition transient and will not
> > > get queued up into the socket past this backlog stage.
> > >
> >
> > Even being transient we need a limit. Without copybreak, an
> > ACK can cost 2048+256 bytes.
> >
> > In my 10Gbit tests (standard netperf using 16K buffers), I've seen
> > backlogs of 300 ACK packets...
>
> What about forcing a copybreak for acks when above the rx buffer size?
> That way you avoid the cost of the copy in teh normal case when
> the data will be freed, but avoid the memory overhead when a lot
> of acks (or rx data) is queued.
Thats noise, as the minimal truesize of an ACK packet is 512 + 256 on
x86_64
The fact that ixgbe provides 1024 + 256 could be fixed in the driver,
its a 4 lines change actually. Then you already have a minimal skb.
^ permalink raw reply
* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: Eric Dumazet @ 2012-04-24 8:49 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: David Miller, rick.jones2, Netdev, therbert, ncardwell, maze,
Yuchung Cheng
In-Reply-To: <alpine.DEB.2.00.1204241026410.735@wel-95.cs.helsinki.fi>
On Tue, 2012-04-24 at 11:01 +0300, Ilpo Järvinen wrote:
> On Tue, 24 Apr 2012, Eric Dumazet wrote:
>
> > On Mon, 2012-04-23 at 22:37 +0200, Eric Dumazet wrote:
> >
> > > We could try to coalesce ACKs before backlogging them. I'll work on
> > > this.
> >
> > I did an experiment, and found a basic coalescing was not working in
> > case of packet loss and SACK storm.
>
> ...That case might also have some performance issues at the receiver end
> when a hole is filled and TCP pushes stuff higher up.
>
> > Doing a smart coalescing in this case sounds really complex.
>
> Why's that? ...We'd compare options 32-bit at a time (like you already do
> anyway) and if we find difference we check the previous bits to validate
> it's a SACK option (the changing one should be in the first start-end
> pair). ...As long as there's no hole in every other segment we'd be
> winners I think.
>
> > Should we really continue this way ?
>
> Why not, but wouldn't it be nicer to coalesce them already in GRO below
> with an assumption that GRO is likely to find some "mss" equivivalent
> which tells the gap between consecutive ACK (or even SACK) seqnos?
>
> I've been long thinking that it would be nice to run offloading for ACKs
> too, and possibly even for SACKs, in both ends, although that might not be
> possible with other than GSO/GRO, at least atm.
>
>
GRO doesnt coalesce pure acks, thats part of GRO contract.
By the way, I find GRO less and less attractive, if we have fragged skbs
provided by drivers, we can do the GRO almost for free in tcp stack,
instead of very complex/duplicated logic before tcp stack.
http://git.kernel.org/?p=linux/kernel/git/davem/net-next.git;a=commit;h=1402d366019fedaa2b024f2bac06b7cc9a8782e1
Doing this coalescing in tcp stack solves many problems GRO is unable to
address, like reordering...
^ permalink raw reply
* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: David Miller @ 2012-04-24 8:48 UTC (permalink / raw)
To: ilpo.jarvinen
Cc: eric.dumazet, rick.jones2, netdev, therbert, ncardwell, maze,
ycheng
In-Reply-To: <alpine.DEB.2.00.1204241131580.735@wel-95.cs.helsinki.fi>
From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Tue, 24 Apr 2012 11:40:27 +0300 (EEST)
> And the problem I mentioned in the previous mail (in the terms of this
> code fragment) is that ackdiff is no longer MSS or 2*MSS because of GRO
> for the opposite direction doesn't trigger all those ACKs a non-GRO
> receiver would.
This is the ACK counting Eric mentioned, which we need to preserve
for the purposes of CWND growth.
And in any event, you cannot depend upon the ACK boundaries in any way
shape or form, 2 * MSS is just one valid mode of ACK'ing.
Whether we get a GRO stretch ACK or a normal 2 * MSS one, it has to
work properly either way.
^ permalink raw reply
* RE: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: David Laight @ 2012-04-24 8:44 UTC (permalink / raw)
To: Eric Dumazet, David Miller
Cc: rick.jones2, netdev, therbert, ncardwell, maze, ycheng,
ilpo.jarvinen
In-Reply-To: <1335213446.5205.65.camel@edumazet-glaptop>
> On Mon, 2012-04-23 at 16:01 -0400, David Miller wrote:
>
> > Hmmm... why don't we just acknowledge reality and special case ACKs?
> >
>
> Yes why not.
>
>
> > If a TCP packet is dataless we should just let it go
> > through no matter what and with no limits.
> > It is by definition transient and will not
> > get queued up into the socket past this backlog stage.
> >
>
> Even being transient we need a limit. Without copybreak, an
> ACK can cost 2048+256 bytes.
>
> In my 10Gbit tests (standard netperf using 16K buffers), I've seen
> backlogs of 300 ACK packets...
What about forcing a copybreak for acks when above the rx buffer size?
That way you avoid the cost of the copy in teh normal case when
the data will be freed, but avoid the memory overhead when a lot
of acks (or rx data) is queued.
David
^ permalink raw reply
* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: Ilpo Järvinen @ 2012-04-24 8:40 UTC (permalink / raw)
To: David Miller
Cc: Eric Dumazet, rick.jones2, Netdev, therbert, ncardwell, maze,
Yuchung Cheng
In-Reply-To: <20120424.042546.2154907239944513463.davem@davemloft.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2021 bytes --]
On Tue, 24 Apr 2012, David Miller wrote:
> From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
> Date: Tue, 24 Apr 2012 11:21:18 +0300 (EEST)
>
> > On Tue, 24 Apr 2012, David Miller wrote:
> >
> >> That makes this a non-starter since we must therefore remember all of
> >> the SACK boundaries in the original packets.
> >
> > GRO works because TCP tends to use rather constant MSS, right? ...Since
> > ACKs and SACKs are nothing more than reflection of those MSS boundaries of
> > the opposite direction I don't find that as impossible as you do because
> > the same kind of "mss" assumption can be applied there. But GRO has made
> > this somewhat messier now because the receiver doesn't any more generate
> > ACK per MSS or ACK per 2*MSS but that could be "fixed" by offloading the
> > ACK sending when responding to a GROed packet.
>
> We're talking about accumulating ACKs on GRO not data packets.
So am I... :-). ...Code speaks more than thousands of words:
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 8bb6ade..33b87b2 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2820,7 +2820,11 @@ found:
flush |= (__force int)(flags & TCP_FLAG_CWR);
flush |= (__force int)((flags ^ tcp_flag_word(th2)) &
~(TCP_FLAG_CWR | TCP_FLAG_FIN | TCP_FLAG_PSH));
- flush |= (__force int)(th->ack_seq ^ th2->ack_seq);
+
+ ackgap = skb_shinfo(p)->ack_size;
+ ackdiff = th2->ack_seq - th->ack_seq;
+ flush |= (ackdiff - 1) >= ackgap;
+
for (i = sizeof(*th); i < thlen; i += 4)
flush |= *(u32 *)((u8 *)th + i) ^
*(u32 *)((u8 *)th2 + i);
...Obviously Data and ACK couldn't be GROed at the same time practically
(would allow reusing the gso_size field for ack_size). ...But why exactly
you think this is not possible or viable solution if fully implemented?
And the problem I mentioned in the previous mail (in the terms of this
code fragment) is that ackdiff is no longer MSS or 2*MSS because of GRO
for the opposite direction doesn't trigger all those ACKs a non-GRO
receiver would.
--
i.
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox