* Hello my love, My name is jane ferguson,i come across and read through your profile today and i became interested in you,i will also like to know you the more,and i want you to send an e-mail to my e-mail address so i can give you my picture for you to know whom i am and for the both of us to know each other very well and better in life,and we can achieve it in future because ture love and feeling means alot in future.Here is my private e-mail address you can contact me with it.(jane.ferguson@gala.net )I am waiting for your mail to my e-mail address above and aslo, Remember the distance or colour does not matter but love,feeling,e-motions and sympathetic love matters alot in life. Thanks,and i promise to be honest and to keep a very good relationship with you. jane. ja ne.ferguson@gala.net
From: jane ferguson @ 2011-09-21 14:08 UTC (permalink / raw)
^ permalink raw reply
* Re: TCP_DELACK_MIN vs TCP_ATO_MIN
From: rohan puri @ 2011-09-21 14:58 UTC (permalink / raw)
To: Daniel Baluta; +Cc: netdev, kernelnewbies
In-Reply-To: <CAEnQRZAObcdhikY6GzG3mC1KZjgK8Xp5LzNetczmZP=BRPqN6w@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2036 bytes --]
On Wed, Sep 21, 2011 at 6:29 PM, Daniel Baluta <daniel.baluta@gmail.com>wrote:
> Hello,
>
> RFC2582, Section 4.2 says:
>
> "... an ACK SHOULD be generated for at least every second
> full-sized segment, and MUST be generated within 500 ms
> of the arrival of the first unacknowledged packet. ".
>
>
> I guess that the delayed ACK timeout is computed in tcp_send_delayed_ack:
>
> ===
> void tcp_send_delayed_ack(struct sock *sk)
> {
> struct inet_connection_sock *icsk = inet_csk(sk);
> int ato = icsk->icsk_ack.ato;
> unsigned long timeout;
>
> /* .... */
> /* Stay within the limit we were given */
> timeout = jiffies + ato;
> ====
>
>
> Can one explain what is the difference between TCP_DELACK_MIN and
> TCP_ATO_MIN, specifically if the timeout (ato) is always in the interval
> [TCP_DELACK_MIN, TCP_DELACK_MAX] ?
>
> I want to make the delayed ack timeout configurable as some guys tried
> here [1],
> so for this reason I plan to make TCP_DELACK_MIN and TCP_DELACK_MAX
> tunable via proc entries.
>
> thanks,
> Daniel.
>
> [1] http://kerneltrap.org/mailarchive/linux-netdev/2008/9/9/3245554
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
Hi Daniel,
TCP in linux makes use of two modes for acking the data received.
1. Quick Ack : - Used at the start of the TCP connection so that the
congestion window can grow fastly.
2. Delayed Ack : - It moves to delayed ack mode, in which ack is sent for
multiple packets.
TCP switches between the two modes depending on the congestion experienced.
In Quick Ack, Ack timeout interval (ato) is set to minimum i.e. TCP_ATO_MIN
while in Delayed Ack mode, TCP_DELACK_MIN is used for restarting/ resetting
the timer.
Now the default value is of both the macros is same.
But if you want to make delayed ack timeout configurable, then I think you
should give proc interface for TCP_DELACK_MIN.
Regards,
Rohan Puri
[-- Attachment #1.2: Type: text/html, Size: 2732 bytes --]
[-- Attachment #2: Type: text/plain, Size: 169 bytes --]
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply
* Re: RFS issue: no HW filter for paused stream
From: Ben Hutchings @ 2011-09-21 15:09 UTC (permalink / raw)
To: amirv; +Cc: Tom Herbert, oren, liranl, netdev, Diego Crupnicoff
In-Reply-To: <4E783855.4020907@dev.mellanox.co.il>
On Tue, 2011-09-20 at 09:53 +0300, Amir Vadai wrote:
> This will unset the current CPU of the rflow that belongs to the desired
> CPU.
> The problem is when the stream resumes and it goes to the wrong RXQ - in
> our HW, it will be according to RSS, as long as there is no specific
> flow steering rule for the stream.
Sorry, yes. Told you I didn't test my patch!
> We need to unset the current CPU of the rflow of the actual RXQ that the
> packet arrived at:
[...]
> Or even better, not set it in the first place - but I'm not sure I
> undersdtand the implications on RPS:
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 4b9981c..748acdb 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2654,7 +2654,7 @@ set_rps_cpu(struct net_device *dev, struct sk_buff
> *skb,
> {
> u16 tcpu;
>
> - tcpu = rflow->cpu = next_cpu;
> + tcpu = next_cpu;
> if (tcpu != RPS_NO_CPU) {
> #ifdef CONFIG_RFS_ACCEL
> struct netdev_rx_queue *rxqueue;
>
>
But that means we never move the flow to a new CPU in the non-
accelerated case. So maybe the proper change would be:
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2652,10 +2652,7 @@ static struct rps_dev_flow *
set_rps_cpu(struct net_device *dev, struct sk_buff *skb,
struct rps_dev_flow *rflow, u16 next_cpu)
{
- u16 tcpu;
-
- tcpu = rflow->cpu = next_cpu;
- if (tcpu != RPS_NO_CPU) {
+ if (next_cpu != RPS_NO_CPU) {
#ifdef CONFIG_RFS_ACCEL
struct netdev_rx_queue *rxqueue;
struct rps_dev_flow_table *flow_table;
@@ -2683,16 +2680,16 @@ set_rps_cpu(struct net_device *dev, struct sk_buff *skb,
goto out;
old_rflow = rflow;
rflow = &flow_table->flows[flow_id];
- rflow->cpu = next_cpu;
rflow->filter = rc;
if (old_rflow->filter == rflow->filter)
old_rflow->filter = RPS_NO_FILTER;
out:
#endif
rflow->last_qtail =
- per_cpu(softnet_data, tcpu).input_queue_head;
+ per_cpu(softnet_data, next_cpu).input_queue_head;
}
+ rflow->cpu = next_cpu;
return rflow;
}
--- END ---
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: TCP_DELACK_MIN vs TCP_ATO_MIN
From: Daniel Baluta @ 2011-09-21 15:28 UTC (permalink / raw)
To: rohan puri; +Cc: netdev, kernelnewbies
In-Reply-To: <CALJfu6MnV0se8YCTWt65=_4PcOhKsbvUgRmaNxbjf7La+4ar4g@mail.gmail.com>
> Now the default value is of both the macros is same.
>
> But if you want to make delayed ack timeout configurable, then I think you
> should give proc interface for TCP_DELACK_MIN.
Thanks Rohan. Then also I have to export TCP_DELACK_MAX since I think
ato cannot grow over this value.
thanks,
Daniel.
^ permalink raw reply
* [PATCH v3 2/3] net/fec: fix fec1 check in fec_enet_mii_init()
From: Shawn Guo @ 2011-09-21 16:07 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-arm-kernel, patches, Shawn Guo
In-Reply-To: <1316621270-27805-1-git-send-email-shawn.guo@linaro.org>
In function fec_enet_mii_init(), it uses non-zero pdev->id as part
of the condition to check the second fec instance (fec1). This works
before the driver supports device tree probe. But in case of device
tree probe, pdev->id is -1 which is also non-zero, so the logic becomes
broken when device tree probe gets supported.
The patch change the logic to check "pdev->id > 0" as the part of the
condition for identifying fec1.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/net/ethernet/freescale/fec.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index 9c1d059..2bbe6a5 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -996,7 +996,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
* mdio interface in board design, and need to be configured by
* fec0 mii_bus.
*/
- if ((id_entry->driver_data & FEC_QUIRK_ENET_MAC) && pdev->id) {
+ if ((id_entry->driver_data & FEC_QUIRK_ENET_MAC) && pdev->id > 0) {
/* fec1 uses fec0 mii_bus */
fep->mii_bus = fec0_mii_bus;
return 0;
--
1.7.4.1
^ permalink raw reply related
* [PATCH v3 3/3] net/fec: add imx6q enet support
From: Shawn Guo @ 2011-09-21 16:07 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-arm-kernel, patches, Shawn Guo
In-Reply-To: <1316621270-27805-1-git-send-email-shawn.guo@linaro.org>
The imx6q enet is a derivative of imx28 enet controller. It fixed
the frame endian issue found on imx28, and added 1 Gbps support.
It also fixes a typo on vendor name in Kconfig.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/net/ethernet/freescale/Kconfig | 9 ++---
drivers/net/ethernet/freescale/fec.c | 61 +++++++++++++++++++++++++------
2 files changed, 53 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
index 4dbe41f..1cf6716 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -7,7 +7,7 @@ config NET_VENDOR_FREESCALE
default y
depends on FSL_SOC || QUICC_ENGINE || CPM1 || CPM2 || PPC_MPC512x || \
M523x || M527x || M5272 || M528x || M520x || M532x || \
- IMX_HAVE_PLATFORM_FEC || MXS_HAVE_PLATFORM_FEC || \
+ ARCH_MXC || ARCH_MXS || \
(PPC_MPC52xx && PPC_BESTCOMM)
---help---
If you have a network (Ethernet) card belonging to this class, say Y
@@ -16,16 +16,15 @@ config NET_VENDOR_FREESCALE
Note that the answer to this question doesn't directly affect the
kernel: saying N will just cause the configurator to skip all
- the questions about IBM devices. If you say Y, you will be asked for
- your specific card in the following questions.
+ the questions about Freescale devices. If you say Y, you will be
+ asked for your specific card in the following questions.
if NET_VENDOR_FREESCALE
config FEC
bool "FEC ethernet controller (of ColdFire and some i.MX CPUs)"
depends on (M523x || M527x || M5272 || M528x || M520x || M532x || \
- IMX_HAVE_PLATFORM_FEC || MXS_HAVE_PLATFORM_FEC)
- default IMX_HAVE_PLATFORM_FEC || MXS_HAVE_PLATFORM_FEC if ARM
+ ARCH_MXC || ARCH_MXS)
select PHYLIB
---help---
Say Y here if you want to use the built-in 10/100 Fast ethernet
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index 2bbe6a5..3101d05 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -18,7 +18,7 @@
* Bug fixes and cleanup by Philippe De Muyter (phdm@macqel.be)
* Copyright (c) 2004-2006 Macq Electronique SA.
*
- * Copyright (C) 2010 Freescale Semiconductor, Inc.
+ * Copyright (C) 2010-2011 Freescale Semiconductor, Inc.
*/
#include <linux/module.h>
@@ -72,6 +72,10 @@
#define FEC_QUIRK_SWAP_FRAME (1 << 1)
/* Controller uses gasket */
#define FEC_QUIRK_USE_GASKET (1 << 2)
+/* Controller has GBIT support */
+#define FEC_QUIRK_HAS_GBIT (1 << 3)
+/* Controller's phy_speed bit field need to minus one */
+#define FEC_QUIRK_PHY_SPEED_MINUS_ONE (1 << 4)
static struct platform_device_id fec_devtype[] = {
{
@@ -88,6 +92,10 @@ static struct platform_device_id fec_devtype[] = {
.name = "imx28-fec",
.driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_SWAP_FRAME,
}, {
+ .name = "imx6q-fec",
+ .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT |
+ FEC_QUIRK_PHY_SPEED_MINUS_ONE,
+ }, {
/* sentinel */
}
};
@@ -97,12 +105,14 @@ enum imx_fec_type {
IMX25_FEC = 1, /* runs on i.mx25/50/53 */
IMX27_FEC, /* runs on i.mx27/35/51 */
IMX28_FEC,
+ IMX6Q_FEC,
};
static const struct of_device_id fec_dt_ids[] = {
{ .compatible = "fsl,imx25-fec", .data = &fec_devtype[IMX25_FEC], },
{ .compatible = "fsl,imx27-fec", .data = &fec_devtype[IMX27_FEC], },
{ .compatible = "fsl,imx28-fec", .data = &fec_devtype[IMX28_FEC], },
+ { .compatible = "fsl,imx6q-fec", .data = &fec_devtype[IMX6Q_FEC], },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, fec_dt_ids);
@@ -373,6 +383,7 @@ fec_restart(struct net_device *ndev, int duplex)
int i;
u32 temp_mac[2];
u32 rcntl = OPT_FRAME_SIZE | 0x04;
+ u32 ecntl = 0x2; /* ETHEREN */
/* Whack a reset. We should wait for this. */
writel(1, fep->hwp + FEC_ECNTRL);
@@ -442,18 +453,23 @@ fec_restart(struct net_device *ndev, int duplex)
/* Enable flow control and length check */
rcntl |= 0x40000000 | 0x00000020;
- /* MII or RMII */
- if (fep->phy_interface == PHY_INTERFACE_MODE_RMII)
+ /* RGMII, RMII or MII */
+ if (fep->phy_interface == PHY_INTERFACE_MODE_RGMII)
+ rcntl |= (1 << 6);
+ else if (fep->phy_interface == PHY_INTERFACE_MODE_RMII)
rcntl |= (1 << 8);
else
rcntl &= ~(1 << 8);
- /* 10M or 100M */
- if (fep->phy_dev && fep->phy_dev->speed == SPEED_100)
- rcntl &= ~(1 << 9);
- else
- rcntl |= (1 << 9);
-
+ /* 1G, 100M or 10M */
+ if (fep->phy_dev) {
+ if (fep->phy_dev->speed == SPEED_1000)
+ ecntl |= (1 << 5);
+ else if (fep->phy_dev->speed == SPEED_100)
+ rcntl &= ~(1 << 9);
+ else
+ rcntl |= (1 << 9);
+ }
} else {
#ifdef FEC_MIIGSK_ENR
if (id_entry->driver_data & FEC_QUIRK_USE_GASKET) {
@@ -478,8 +494,15 @@ fec_restart(struct net_device *ndev, int duplex)
}
writel(rcntl, fep->hwp + FEC_R_CNTRL);
+ if (id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
+ /* enable ENET endian swap */
+ ecntl |= (1 << 8);
+ /* enable ENET store and forward mode */
+ writel(1 << 8, fep->hwp + FEC_X_WMRK);
+ }
+
/* And last, enable the transmit and receive processing */
- writel(2, fep->hwp + FEC_ECNTRL);
+ writel(ecntl, fep->hwp + FEC_ECNTRL);
writel(0, fep->hwp + FEC_R_DES_ACTIVE);
/* Enable interrupts we wish to service */
@@ -490,6 +513,8 @@ static void
fec_stop(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
+ const struct platform_device_id *id_entry =
+ platform_get_device_id(fep->pdev);
/* We cannot expect a graceful transmit stop without link !!! */
if (fep->link) {
@@ -504,6 +529,10 @@ fec_stop(struct net_device *ndev)
udelay(10);
writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
writel(FEC_DEFAULT_IMASK, fep->hwp + FEC_IMASK);
+
+ /* We have to keep ENET enabled to have MII interrupt stay working */
+ if (id_entry->driver_data & FEC_QUIRK_ENET_MAC)
+ writel(2, fep->hwp + FEC_ECNTRL);
}
@@ -918,6 +947,8 @@ static int fec_enet_mdio_reset(struct mii_bus *bus)
static int fec_enet_mii_probe(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
+ const struct platform_device_id *id_entry =
+ platform_get_device_id(fep->pdev);
struct phy_device *phy_dev = NULL;
char mdio_bus_id[MII_BUS_ID_SIZE];
char phy_name[MII_BUS_ID_SIZE + 3];
@@ -949,14 +980,18 @@ static int fec_enet_mii_probe(struct net_device *ndev)
snprintf(phy_name, MII_BUS_ID_SIZE, PHY_ID_FMT, mdio_bus_id, phy_id);
phy_dev = phy_connect(ndev, phy_name, &fec_enet_adjust_link, 0,
- PHY_INTERFACE_MODE_MII);
+ fep->phy_interface);
if (IS_ERR(phy_dev)) {
printk(KERN_ERR "%s: could not attach to PHY\n", ndev->name);
return PTR_ERR(phy_dev);
}
/* mask with MAC supported features */
- phy_dev->supported &= PHY_BASIC_FEATURES;
+ if (id_entry->driver_data & FEC_QUIRK_HAS_GBIT)
+ phy_dev->supported &= PHY_GBIT_FEATURES;
+ else
+ phy_dev->supported &= PHY_BASIC_FEATURES;
+
phy_dev->advertising = phy_dev->supported;
fep->phy_dev = phy_dev;
@@ -1008,6 +1043,8 @@ static int fec_enet_mii_init(struct platform_device *pdev)
* Set MII speed to 2.5 MHz (= clk_get_rate() / 2 * phy_speed)
*/
fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000) << 1;
+ if (id_entry->driver_data & FEC_QUIRK_PHY_SPEED_MINUS_ONE)
+ fep->phy_speed--;
writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
fep->mii_bus = mdiobus_alloc();
--
1.7.4.1
^ permalink raw reply related
* [PATCH v3 1/3] net/fec: fec_reset_phy() does not need to always succeed
From: Shawn Guo @ 2011-09-21 16:07 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-arm-kernel, patches, Shawn Guo
In-Reply-To: <1316621270-27805-1-git-send-email-shawn.guo@linaro.org>
FEC can work without a phy reset on some platforms, which means not
very platform necessarily have a phy-reset gpio encoded in device tree.
Even on the platforms that have the gpio, FEC can work without
resetting phy for some cases, e.g. boot loader has done that.
So it makes more sense to have the phy-reset-gpio request failure as
a debug message rather than a warning, and get fec_reset_phy() return
void since the caller does not check the return anyway.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/net/ethernet/freescale/fec.c | 13 +++++--------
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index 158b82e..9c1d059 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -1411,24 +1411,22 @@ static int __devinit fec_get_phy_mode_dt(struct platform_device *pdev)
return -ENODEV;
}
-static int __devinit fec_reset_phy(struct platform_device *pdev)
+static void __devinit fec_reset_phy(struct platform_device *pdev)
{
int err, phy_reset;
struct device_node *np = pdev->dev.of_node;
if (!np)
- return -ENODEV;
+ return;
phy_reset = of_get_named_gpio(np, "phy-reset-gpios", 0);
err = gpio_request_one(phy_reset, GPIOF_OUT_INIT_LOW, "phy-reset");
if (err) {
- pr_warn("FEC: failed to get gpio phy-reset: %d\n", err);
- return err;
+ pr_debug("FEC: failed to get gpio phy-reset: %d\n", err);
+ return;
}
msleep(1);
gpio_set_value(phy_reset, 1);
-
- return 0;
}
#else /* CONFIG_OF */
static inline int fec_get_phy_mode_dt(struct platform_device *pdev)
@@ -1436,13 +1434,12 @@ static inline int fec_get_phy_mode_dt(struct platform_device *pdev)
return -ENODEV;
}
-static inline int fec_reset_phy(struct platform_device *pdev)
+static inline void fec_reset_phy(struct platform_device *pdev)
{
/*
* In case of platform probe, the reset has been done
* by machine code.
*/
- return 0;
}
#endif /* CONFIG_OF */
--
1.7.4.1
^ permalink raw reply related
* [PATCH v3 0/3] add fec support for imx6q
From: Shawn Guo @ 2011-09-21 16:07 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-arm-kernel, patches
This series adds imx6q enet support. The imx6q enet is a derivative of
imx28 enet controller. It fixed the frame endian issue found on imx28,
and added 1 Gbps support.
Changes since v2:
* Refine patch #1 to get fec_reset_phy() return void
Changes since v1:
* Fix typo pointed out by Francois Romieu
* Drop patch #3 in the v1
* Rebase on net-next tree
Thanks.
Shawn Guo (3):
net/fec: fec_reset_phy() does not need to always succeed
net/fec: fix fec1 check in fec_enet_mii_init()
net/fec: add imx6q enet support
drivers/net/ethernet/freescale/Kconfig | 9 ++--
drivers/net/ethernet/freescale/fec.c | 76 +++++++++++++++++++++++---------
2 files changed, 59 insertions(+), 26 deletions(-)
^ permalink raw reply
* Re: [PATCH 39/57] net: irq: Remove IRQF_DISABLED
From: David Miller @ 2011-09-21 17:40 UTC (permalink / raw)
To: yong.zhang0
Cc: linux-arch, linux-kernel, tglx, perex, leitao, olof, nico,
steve.glendinning, geoff, t.sailer, jreuter, klaus.kudielka, jpr,
samuel, chunkeey, linville, jeffrey.t.kirsher, jpirko, bob.liu,
grundler, ralf, blogic, marc, lucas.demarchi, joe,
uclinux-dist-devel, netdev, cbe-oss-dev, linux-hams,
linux-wireless
In-Reply-To: <1316597339-29861-40-git-send-email-yong.zhang0@gmail.com>
From: Yong Zhang <yong.zhang0@gmail.com>
Date: Wed, 21 Sep 2011 17:28:40 +0800
> Since commit [c58543c8: genirq: Run irq handlers with interrupts disabled],
> We run all interrupt handlers with interrupts disabled
> and we even check and yell when an interrupt handler
> returns with interrupts enabled (see commit [b738a50a:
> genirq: Warn when handler enables interrupts]).
>
> So now this flag is a NOOP and can be removed.
>
> Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* (unknown),
From: Coca Cola @ 2011-09-21 18:16 UTC (permalink / raw)
Attn: Sir/Madam,
This is to inform you that you have won
$ 1,000,000.00 (One Million Dollars) in
Coca Cola seasonal promo. Further
informations will be shared upon
response from you.
Thank you,
Kevin Howards,
Regional Director
Coca Cola Plc.
^ permalink raw reply
* Re: [PATCH v3 2/7] socket: initial cgroup code.
From: Greg Thelen @ 2011-09-21 18:47 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
netdev, linux-mm, kirill
In-Reply-To: <1316393805-3005-3-git-send-email-glommer@parallels.com>
On Sun, Sep 18, 2011 at 5:56 PM, Glauber Costa <glommer@parallels.com> wrote:
> We aim to control the amount of kernel memory pinned at any
> time by tcp sockets. To lay the foundations for this work,
> this patch adds a pointer to the kmem_cgroup to the socket
> structure.
>
> Signed-off-by: Glauber Costa <glommer@parallels.com>
> CC: David S. Miller <davem@davemloft.net>
> CC: Hiroyouki Kamezawa <kamezawa.hiroyu@jp.fujitsu.com>
> CC: Eric W. Biederman <ebiederm@xmission.com>
...
> +void sock_update_memcg(struct sock *sk)
> +{
> + /* right now a socket spends its whole life in the same cgroup */
> + BUG_ON(sk->sk_cgrp);
> +
> + rcu_read_lock();
> + sk->sk_cgrp = mem_cgroup_from_task(current);
> +
> + /*
> + * We don't need to protect against anything task-related, because
> + * we are basically stuck with the sock pointer that won't change,
> + * even if the task that originated the socket changes cgroups.
> + *
> + * What we do have to guarantee, is that the chain leading us to
> + * the top level won't change under our noses. Incrementing the
> + * reference count via cgroup_exclude_rmdir guarantees that.
> + */
> + cgroup_exclude_rmdir(mem_cgroup_css(sk->sk_cgrp));
This grabs a css_get() reference, which prevents rmdir (will return
-EBUSY). How long is this reference held? I wonder about the case
where a process creates a socket in memcg M1 and later is moved into
memcg M2. At that point an admin would expect to be able to 'rmdir
M1'. I think this rmdir would return -EBUSY and I suspect it would be
difficult for the admin to understand why the rmdir of M1 failed. It
seems that to rmdir a memcg, an admin would have to kill all processes
that allocated sockets while in M1. Such processes may not still be
in M1.
> + rcu_read_unlock();
> +}
^ permalink raw reply
* Re: [PATCH v3 2/7] socket: initial cgroup code.
From: Glauber Costa @ 2011-09-21 18:59 UTC (permalink / raw)
To: Greg Thelen
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
netdev, linux-mm, kirill
In-Reply-To: <CAHH2K0YgkG2J_bO+U9zbZYhTTqSLvr6NtxKxN8dRtfHs=iB8iA@mail.gmail.com>
On 09/21/2011 03:47 PM, Greg Thelen wrote:
> On Sun, Sep 18, 2011 at 5:56 PM, Glauber Costa<glommer@parallels.com> wrote:
>> We aim to control the amount of kernel memory pinned at any
>> time by tcp sockets. To lay the foundations for this work,
>> this patch adds a pointer to the kmem_cgroup to the socket
>> structure.
>>
>> Signed-off-by: Glauber Costa<glommer@parallels.com>
>> CC: David S. Miller<davem@davemloft.net>
>> CC: Hiroyouki Kamezawa<kamezawa.hiroyu@jp.fujitsu.com>
>> CC: Eric W. Biederman<ebiederm@xmission.com>
> ...
>> +void sock_update_memcg(struct sock *sk)
>> +{
>> + /* right now a socket spends its whole life in the same cgroup */
>> + BUG_ON(sk->sk_cgrp);
>> +
>> + rcu_read_lock();
>> + sk->sk_cgrp = mem_cgroup_from_task(current);
>> +
>> + /*
>> + * We don't need to protect against anything task-related, because
>> + * we are basically stuck with the sock pointer that won't change,
>> + * even if the task that originated the socket changes cgroups.
>> + *
>> + * What we do have to guarantee, is that the chain leading us to
>> + * the top level won't change under our noses. Incrementing the
>> + * reference count via cgroup_exclude_rmdir guarantees that.
>> + */
>> + cgroup_exclude_rmdir(mem_cgroup_css(sk->sk_cgrp));
>
> This grabs a css_get() reference, which prevents rmdir (will return
> -EBUSY).
Yes.
How long is this reference held?
For the socket lifetime.
> I wonder about the case
> where a process creates a socket in memcg M1 and later is moved into
> memcg M2. At that point an admin would expect to be able to 'rmdir
> M1'. I think this rmdir would return -EBUSY and I suspect it would be
> difficult for the admin to understand why the rmdir of M1 failed. It
> seems that to rmdir a memcg, an admin would have to kill all processes
> that allocated sockets while in M1. Such processes may not still be
> in M1.
>
>> + rcu_read_unlock();
>> +}
I agree. But also, don't see too much ways around it without
implementing full task migration.
Right now I am working under the assumption that tasks are long lived
inside the cgroup. Migration potentially introduces some nasty locking
problems in the mem_schedule path.
Also, unless I am missing something, the memcg already has the policy of
not carrying charges around, probably because of this very same complexity.
True that at least it won't EBUSY you... But I think this is at least a
way to guarantee that the cgroup under our nose won't disappear in the
middle of our allocations.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [net-next 0/8][pull request] Intel Wired LAN Driver Update
From: David Miller @ 2011-09-21 19:13 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo
In-Reply-To: <1316599974-23205-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 21 Sep 2011 03:12:46 -0700
> - reconfigure SR-IOV init to take advantage of the new pci flag
Has this gotten any review from the PCI maintainers?
^ permalink raw reply
* Re: [PATCH resend] fib:fix BUG_ON in fib_nl_newrule when add new fib rule
From: David Miller @ 2011-09-21 19:17 UTC (permalink / raw)
To: wanlong.gao; +Cc: linux-kernel, netdev, omarapazanadi, gaofeng, eric.dumazet
In-Reply-To: <1315791365-5324-1-git-send-email-wanlong.gao@gmail.com>
From: Wanlong Gao <wanlong.gao@gmail.com>
Date: Mon, 12 Sep 2011 09:36:05 +0800
> From: Gao feng <gaofeng@cn.fujitsu.com>
>
> add new fib rule can cause BUG_ON happen
> the reproduce shell is
> ip rule add pref 38
> ip rule add pref 38
> ip rule add to 192.168.3.0/24 goto 38
> ip rule del pref 38
> ip rule add to 192.168.3.0/24 goto 38
> ip rule add pref 38
>
> then the BUG_ON will happen
> del BUG_ON and use (ctarget == NULL) identify whether this rule is unresolved
>
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH] net/smsc911x: Correctly configure 16-bit register access from DT
From: David Miller @ 2011-09-21 19:18 UTC (permalink / raw)
To: dave.martin
Cc: netdev, patches, steve.glendinning, shawn.guo, devicetree-discuss
In-Reply-To: <1315910969-4018-1-git-send-email-dave.martin@linaro.org>
From: Dave Martin <dave.martin@linaro.org>
Date: Tue, 13 Sep 2011 11:49:29 +0100
> The SMSC911X_USE_16BIT needs to be set when using 16-bit register
> access. However, currently no flag is set if the device tree
> doesn't specify 32-bit access, resulting in a BUG() and a non-
> working driver when 16-bit register access is configured for
> smsc911x in the DT.
>
> This patch should set the SMSC911X_USE_16BIT flag in a manner
> consistent with the documented DT bindings.
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] xfrm: Perform a replay check after return from async codepaths
From: David Miller @ 2011-09-21 19:21 UTC (permalink / raw)
To: herbert; +Cc: steffen.klassert, netdev
In-Reply-To: <20110921122442.GA19162@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.hengli.com.au>
Date: Wed, 21 Sep 2011 22:24:42 +1000
> On Wed, Sep 21, 2011 at 01:57:27PM +0200, Steffen Klassert wrote:
>>
>> Well, I've got pretty reproduceable crashes when the sender of
>> the IPsec packets introduces reorder, that's why I noticed this.
>>
>> The problem is, that the replay check function is called before
>> the asynchronous crypto processing and the replay advance function
>> is called after resume from the asynchronous processing. So
>> we can submit multiple packets to the crypto layer without
>> updating the replay window. This means that the replay check
>> function accepts packets that should have been dropped, because
>> they are reordered and more than 'replay window size' packets
>> to late. This leads to a crash as we try to update the replay
>> window beyond the allocated bounds.
>
> OK I see what you mean now.
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks everyone.
^ permalink raw reply
* Re: pull request: batman-adv 2011-09-08
From: David Miller @ 2011-09-21 19:26 UTC (permalink / raw)
To: lindner_marek-LWAfsSFWpa4
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <1315500051-1122-1-git-send-email-lindner_marek-LWAfsSFWpa4@public.gmane.org>
From: Marek Lindner <lindner_marek-LWAfsSFWpa4@public.gmane.org>
Date: Thu, 8 Sep 2011 18:40:44 +0200
> The following changes since commit a943cac144e035c21d4f1b31b95f15b33c33a480:
>
> batman-adv: merge update_transtable() into tt related code (2011-08-22 15:16:22 +0200)
>
> are available in the git repository at:
> git://git.open-mesh.org/linux-merge.git batman-adv/next
Pulled, thanks Marek.
^ permalink raw reply
* [patch 1/1] connector: add comm change event report to proc connector
From: akpm @ 2011-09-21 19:26 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, vzapolskiy, zbr
From: Vladimir Zapolskiy <vzapolskiy@gmail.com>
Subject: connector: add comm change event report to proc connector
Add an event to monitor comm value changes of tasks. Such an event
becomes vital, if someone desires to control threads of a process in
different manner.
A natural characteristic of threads is its comm value, and helpfully
application developers have an opportunity to change it in runtime.
Reporting about such events via proc connector allows to fine-grain
monitoring and control potentials, for instance a process control daemon
listening to proc connector and following comm value policies can place
specific threads to assigned cgroup partitions.
It might be possible to achieve a pale partial one-shot likeness without
this update, if an application changes comm value of a thread generator
task beforehand, then a new thread is cloned, and after that proc
connector listener gets the fork event and reads new thread's comm value
from procfs stat file, but this change visibly simplifies and extends the
matter.
Signed-off-by: Vladimir Zapolskiy <vzapolskiy@gmail.com>
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@google.com>
---
drivers/connector/cn_proc.c | 26 ++++++++++++++++++++++++++
include/linux/cn_proc.h | 11 +++++++++++
kernel/sys.c | 1 +
3 files changed, 38 insertions(+)
diff -puN drivers/connector/cn_proc.c~connector-add-comm-change-event-report-to-proc-connector drivers/connector/cn_proc.c
--- a/drivers/connector/cn_proc.c~connector-add-comm-change-event-report-to-proc-connector
+++ a/drivers/connector/cn_proc.c
@@ -205,6 +205,32 @@ void proc_ptrace_connector(struct task_s
cn_netlink_send(msg, CN_IDX_PROC, GFP_KERNEL);
}
+void proc_comm_connector(struct task_struct *task)
+{
+ struct cn_msg *msg;
+ struct proc_event *ev;
+ struct timespec ts;
+ __u8 buffer[CN_PROC_MSG_SIZE];
+
+ if (atomic_read(&proc_event_num_listeners) < 1)
+ return;
+
+ msg = (struct cn_msg *)buffer;
+ ev = (struct proc_event *)msg->data;
+ get_seq(&msg->seq, &ev->cpu);
+ ktime_get_ts(&ts); /* get high res monotonic timestamp */
+ put_unaligned(timespec_to_ns(&ts), (__u64 *)&ev->timestamp_ns);
+ ev->what = PROC_EVENT_COMM;
+ ev->event_data.comm.process_pid = task->pid;
+ ev->event_data.comm.process_tgid = task->tgid;
+ get_task_comm(ev->event_data.comm.comm, task);
+
+ memcpy(&msg->id, &cn_proc_event_id, sizeof(msg->id));
+ msg->ack = 0; /* not used */
+ msg->len = sizeof(*ev);
+ cn_netlink_send(msg, CN_IDX_PROC, GFP_KERNEL);
+}
+
void proc_exit_connector(struct task_struct *task)
{
struct cn_msg *msg;
diff -puN include/linux/cn_proc.h~connector-add-comm-change-event-report-to-proc-connector include/linux/cn_proc.h
--- a/include/linux/cn_proc.h~connector-add-comm-change-event-report-to-proc-connector
+++ a/include/linux/cn_proc.h
@@ -54,6 +54,7 @@ struct proc_event {
PROC_EVENT_GID = 0x00000040,
PROC_EVENT_SID = 0x00000080,
PROC_EVENT_PTRACE = 0x00000100,
+ PROC_EVENT_COMM = 0x00000200,
/* "next" should be 0x00000400 */
/* "last" is the last process event: exit */
PROC_EVENT_EXIT = 0x80000000
@@ -103,6 +104,12 @@ struct proc_event {
__kernel_pid_t tracer_tgid;
} ptrace;
+ struct comm_proc_event {
+ __kernel_pid_t process_pid;
+ __kernel_pid_t process_tgid;
+ char comm[16];
+ } comm;
+
struct exit_proc_event {
__kernel_pid_t process_pid;
__kernel_pid_t process_tgid;
@@ -118,6 +125,7 @@ void proc_exec_connector(struct task_str
void proc_id_connector(struct task_struct *task, int which_id);
void proc_sid_connector(struct task_struct *task);
void proc_ptrace_connector(struct task_struct *task, int which_id);
+void proc_comm_connector(struct task_struct *task);
void proc_exit_connector(struct task_struct *task);
#else
static inline void proc_fork_connector(struct task_struct *task)
@@ -133,6 +141,9 @@ static inline void proc_id_connector(str
static inline void proc_sid_connector(struct task_struct *task)
{}
+static inline void proc_comm_connector(struct task_struct *task)
+{}
+
static inline void proc_ptrace_connector(struct task_struct *task,
int ptrace_id)
{}
diff -puN kernel/sys.c~connector-add-comm-change-event-report-to-proc-connector kernel/sys.c
--- a/kernel/sys.c~connector-add-comm-change-event-report-to-proc-connector
+++ a/kernel/sys.c
@@ -1760,6 +1760,7 @@ SYSCALL_DEFINE5(prctl, int, option, unsi
sizeof(me->comm) - 1) < 0)
return -EFAULT;
set_task_comm(me, comm);
+ proc_comm_connector(me);
return 0;
case PR_GET_NAME:
get_task_comm(comm, me);
_
^ permalink raw reply
* Re: [PATCH] macmace, macsonic: cleanup
From: David Miller @ 2011-09-21 19:31 UTC (permalink / raw)
To: fthain; +Cc: linux-m68k, netdev
In-Reply-To: <alpine.LNX.2.00.1109140317300.20729@nippy.intranet>
From: Finn Thain <fthain@telegraphics.com.au>
Date: Wed, 14 Sep 2011 03:30:25 +1000 (EST)
>
> We check ether_type before registering the platform device in
> arch/m68k/mac/config.c. Doing the same test again in the driver is
> redundant so remove it.
>
> Multiple probes should not happen since the conversion to platform devices,
> so lose that test too.
>
> Then macmace.c need not include macintosh.h, so remove that and irq.h and
> include linux/interrupt.h explicitly.
>
> Tested on PowerBook 520, Quadra 660av, LC 630.
>
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Applied to net-next, thanks.
^ permalink raw reply
* [RFC PATCH] net: Always fire at least one linkwatch event
From: Neil Horman @ 2011-09-21 19:51 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, David S. Miller, jfeeney
It was recently noted that the tg3 driver had a problem in that after boot a
kernel and if-upping the tg3 interface the sysfs operstate attribute continued
to read 'unkown'. This was happening because tg3 assumes the default carrier
state (which is to say the __LINK_STATE_NOCARRIER bit is clear) is correct.
That said, when the device is if-upped, and the open path, calls
netif_carrier_on, the test_and_set_bit call in that function returns false
(since the bit was previously zero from its initial state). This means that
netif_carrier_on call never generates a linkwatch event, and as a result
dev->operstate never gets recomputed. This could be fixed by unconditionally
calling netif_carrier_off in the probe routine, to simply force a state change
on that bit, but that seems like a sub-par solution, given that many drivers may
have this error. Instead it seems like it might be better to burn an extra bit
in the state field to indicate that the CARRIER bit is still in the initial
state and our first call to netif_carrier_[off|on] should always fire a
linkwatch event.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: jfeeney@redhat.com
---
include/linux/netdevice.h | 1 +
net/sched/sch_generic.c | 8 ++++++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 0a7f619..85d6f68 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -306,6 +306,7 @@ enum netdev_state_t {
__LINK_STATE_NOCARRIER,
__LINK_STATE_LINKWATCH_PENDING,
__LINK_STATE_DORMANT,
+ __LINK_STATE_CARRIER_INIT,
};
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 69fca27..6f8bfd1 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -298,7 +298,9 @@ static void dev_watchdog_down(struct net_device *dev)
*/
void netif_carrier_on(struct net_device *dev)
{
- if (test_and_clear_bit(__LINK_STATE_NOCARRIER, &dev->state)) {
+ int force = !test_and_set_bit(__LINK_STATE_CARRIER_INIT, &dev->state);
+
+ if (test_and_clear_bit(__LINK_STATE_NOCARRIER, &dev->state) || force) {
if (dev->reg_state == NETREG_UNINITIALIZED)
return;
linkwatch_fire_event(dev);
@@ -316,7 +318,9 @@ EXPORT_SYMBOL(netif_carrier_on);
*/
void netif_carrier_off(struct net_device *dev)
{
- if (!test_and_set_bit(__LINK_STATE_NOCARRIER, &dev->state)) {
+ int force = !test_and_set_bit(__LINK_STATE_CARRIER_INIT, &dev->state);
+
+ if (!test_and_set_bit(__LINK_STATE_NOCARRIER, &dev->state) || force) {
if (dev->reg_state == NETREG_UNINITIALIZED)
return;
linkwatch_fire_event(dev);
--
1.7.6.2
^ permalink raw reply related
* RE: [net-next 0/8][pull request] Intel Wired LAN Driver Update
From: Rose, Gregory V @ 2011-09-21 19:58 UTC (permalink / raw)
To: David Miller, Kirsher, Jeffrey T
Cc: netdev@vger.kernel.org, gospo@redhat.com, konrad.wilk@oracle.com,
ijc@hellion.org.uk
In-Reply-To: <20110921.151345.393155542435419672.davem@davemloft.net>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of David Miller
> Sent: Wednesday, September 21, 2011 12:14 PM
> To: Kirsher, Jeffrey T
> Cc: netdev@vger.kernel.org; gospo@redhat.com
> Subject: Re: [net-next 0/8][pull request] Intel Wired LAN Driver Update
>
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Wed, 21 Sep 2011 03:12:46 -0700
>
> > - reconfigure SR-IOV init to take advantage of the new pci flag
>
> Has this gotten any review from the PCI maintainers?
Yes, when it was posted as an RFC back in July. It was deemed acceptable at the time.
See inline mail below.
We probably should have copied Ian Campbell on Konrad Wilk. I have added them to the CC line in this response.
- Greg
From: netdev-owner@vger.kernel.org on behalf of Rose, Gregory V [gregory.v.rose@intel.com]
Sent: Friday, July 29, 2011 9:55 AM
To: Jesse Barnes; Ian Campbell
Cc: Konrad Rzeszutek Wilk; netdev@vger.kernel.org; davem@davemloft.net; bhutchings@solarflare.com; Kirsher, Jeffrey T; linux-pci@vger.kernel.org
Subject: RE: [RFC net-next PATCH 1/4] pci: Add flag indicating device has been assigned by KVM
> -----Original Message-----
> From: Jesse Barnes [mailto:jbarnes@virtuousgeek.org]
> Sent: Friday, July 29, 2011 9:52 AM
> To: Ian Campbell
> Cc: Rose, Gregory V; Konrad Rzeszutek Wilk; netdev@vger.kernel.org;
> davem@davemloft.net; bhutchings@solarflare.com; Kirsher, Jeffrey T; linux-
> pci@vger.kernel.org
> Subject: Re: [RFC net-next PATCH 1/4] pci: Add flag indicating device has
> been assigned by KVM
>
> On Thu, 28 Jul 2011 16:11:17 +0100
> Ian Campbell <ijc@hellion.org.uk> wrote:
>
> > On Wed, 2011-07-27 at 15:17 -0700, Greg Rose wrote:
> > > Device drivers that create and destroy SR-IOV virtual functions via
> > > calls to pci_enable_sriov() and pci_disable_sriov can cause
> catastrophic
> > > failures if they attempt to destroy VFs while they are assigned to
> > > guest virtual machines. By adding a flag for use by the KVM module
> > > to indicate that a device is assigned a device driver can check that
> > > flag and avoid destroying VFs while they are assigned and avoid system
> > > failures.
> > >
> > > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > > ---
> > >
> > > include/linux/pci.h | 2 ++
> >
> > I added Jesse and linux-pci to CC.
> >
> > > virt/kvm/assigned-dev.c | 2 ++
> > > virt/kvm/iommu.c | 4 ++++
> > > 3 files changed, 8 insertions(+), 0 deletions(-)
> >
> > I suppose this would also be useful in Xen's pciback or any other system
> > which does passthrough? (Konrad CC'd for pciback)
> >
> > Is there some common lower layer we could hook this in to? (does
> > iommu_attach/detach_device make sense?) Or shall we just add the flag
> > manipulations to pciback as well?
> >
> > Ian.
> >
> > >
> > > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > > index 2d29218..a297ca2 100644
> > > --- a/include/linux/pci.h
> > > +++ b/include/linux/pci.h
> > > @@ -174,6 +174,8 @@ enum pci_dev_flags {
> > > PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG = (__force pci_dev_flags_t) 1,
> > > /* Device configuration is irrevocably lost if disabled into D3 */
> > > PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) 2,
> > > + /* Provide indication device is assigned by KVM */
> > > + PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
> > > };
>
> Looks fine, but I'd make the comment less redundant with the code, e.g.
> "set when the device is assigned to a guest instance" or somesuch.
Sure, sounds good to me.
Rev 2 of the RFC patches will be out in a couple of weeks, I'm away next week.
Thanks,
- Greg
>
> --
> Jesse Barnes, Intel Open Source Technology Center
--
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
* [GIT] Networking
From: David Miller @ 2011-09-21 20:30 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
Highlights: IPSEC crash fix, ipv4 FIB rule BUG trigger fix, cure
wireless regression that hard-hangs some APs, eliminate deadlock in
ipw2x00 driver, add bluetooth device IDs for current generation
Mac Mini and Macbook Air.
1) Fix IPSEC crash due to misplaced replay check, from Steffen Klassert.
2) iwlagn revert as a workaround for behavior which has been found to
hard-hang some wireless APs. From Don Fry.
3) FIB rule insertion can trigger BUG in fib_nl_newrule() if the rule
already has a ctarget. Fix from Gao Feng.
4) Fix DMA address validation in IXGBE, from Jesse Brandeburg.
5) Fix tg3 VLAN regression on outbound packets, from Kasper Pedersen.
6) Fix pxa168_eth build failure, missing interrupt.h include, from Tanmay
Upadhyay.
7) netconsole needs to init after built-in drivers, from Lin Ming.
8) gianfar classifier rule handler walks past end of array, fix from
Ben Hutchings.
9) Fix MTU fragment calculations in ppp, we generate frags in situations
where the packet actually fits. From Henry WOng.
10) greth accidently corrupts computed checksum on TX, this happens in the
case where the stack has fully computed the checksum already in sw.
Fix from Daniel Hellstrom.
11) Fix double-free in ipv6_add_dev() failure path. From Roy Li.
12) b43 should not issue wireless beacons in ad-hoc mode, fix from Manual Munz.
13) Add bluetooth device IDs for 2011 Mac Mini and Macbook Air, from Jurgen
Kramer and Pieter-Augustijn Van Malleghem.
14) r8169 bug fixes from Hayes Wang and Francois Romieu:
a) Make sure TX processes are really stopped on rtl8111ev1 before
spinning on TXCFG_EMPTY bit to clear.
b) Add missing MODULE_FIRMWARE entry for RTL8111E-VL
c) Set proper RxConfig bits when wake-on-lan is enabled.
d) Fix intepretation of RX descriptor status bits.
e) Only check TBI bit in PHY status on old 8169 parts.
15) Make sure rate mask is updated properly in cfg80211_conn_scan(), from
Rajkumar Manoharan.
16) rtl2800usb MAC address storage endian fix, from Larry Finger.
17) Fix rx2x00 compile error on PowerPC.
18) Fix RTNL mutex deadlock regression in ipw2x00 driver. From Stanislaw Gruszka.
19) Make sure beacon hint flag is cleared when necessary, otherwise updates
are ignored and lost. From Rajkumar Manoharan.
20) Fix ordering of HCI_MGMT vs. HCI_INQUIRY state bits in bluetooth to
fix scanning timeouts. From Oliver Neukum.
Please pull, thanks a lot!
The following changes since commit 38867a28a7dc9d69389990bcd42f6b7c77da3d9d:
Merge branch 'fixes' of git://git.linaro.org/people/arnd/arm-soc (2011-09-20 14:23:16 -0700)
are available in the git repository at:
git://github.com/davem330/net.git master
Ben Hutchings (1):
gianfar: Fix overflow check and return value for gfar_get_cls_all()
Chen Ganir (1):
Bluetooth: Fixed BT ST Channel reg order
Daniel Hellstrom (2):
GRETH: RX/TX bytes were never increased
GRETH: avoid overwrite IP-stack's IP-frags checksum
David S. Miller (1):
Merge branch 'davem.r8169.fixes' of git://violet.fr.zoreil.com/romieu/linux
Don Fry (1):
iwlagn: workaround bug crashing some APs
Francois Romieu (2):
r8169: remove erroneous processing of always set bit.
r8169: do not enable the TBI for anything but the original 8169.
Gao feng (1):
fib:fix BUG_ON in fib_nl_newrule when add new fib rule
Hayes Wang (3):
r8169: fix the reset setting for 8111evl
r8169: add MODULE_FIRMWARE for the firmware of 8111evl
r8169: fix WOL setting for 8105 and 8111evl
Henry Wong (1):
ppp_generic: fix multilink fragment MTU calculation (again)
Jesse Brandeburg (1):
ixgbe: fix possible null buffer error
John W. Linville (2):
Merge branch 'for-3.1' of git://github.com/padovan/bluetooth-next
Merge branch 'master' of ssh://infradead/~/public_git/wireless into for-davem
Jurgen Kramer (1):
Bluetooth: add support for 2011 mac mini
Kasper Pedersen (1):
tg3: fix VLAN tagging regression
Larry Finger (2):
rt2800pci: Fix compiler error on PowerPC
rtl2800usb: Fix incorrect storage of MAC address on big-endian platforms
Lin Ming (1):
netconsole: switch init_netconsole() to late_initcall
Manual Munz (1):
b43: Fix beacon problem in ad-hoc mode
Oliver Neukum (1):
Bluetooth: Fix timeout on scanning for the second time
Pieter-Augustijn Van Malleghem (1):
Bluetooth: Add MacBookAir4,1 support
Rajkumar Manoharan (2):
wireless: Reset beacon_found while updating regulatory
wireless: Fix rate mask for scan request
Roy Li (1):
ipv6: fix a possible double free
Stanislaw Gruszka (1):
ipw2x00: fix rtnl mutex deadlock
Steffen Klassert (1):
xfrm: Perform a replay check after return from async codepaths
Tanmay Upadhyay (1):
net: pxa168: Fix build errors by including interrupt.h
drivers/bluetooth/btusb.c | 6 ++++
drivers/bluetooth/btwilink.c | 16 +++++-----
drivers/net/gianfar_ethtool.c | 8 ++--
drivers/net/greth.c | 12 ++++++-
drivers/net/greth.h | 1 +
drivers/net/ixgbe/ixgbe_main.c | 4 +-
drivers/net/netconsole.c | 8 ++++-
drivers/net/ppp_generic.c | 7 ++++-
drivers/net/pxa168_eth.c | 1 +
drivers/net/r8169.c | 32 +++++++++++++++++---
drivers/net/tg3.c | 2 -
drivers/net/wireless/b43/main.c | 3 +-
drivers/net/wireless/ipw2x00/ipw2100.c | 21 +++++++++----
drivers/net/wireless/ipw2x00/ipw2200.c | 39 +++++++++++++++++--------
drivers/net/wireless/iwlwifi/iwl-agn.c | 5 +++
drivers/net/wireless/rt2x00/rt2800lib.c | 47 +++++++++++++++++--------------
net/bluetooth/hci_event.c | 17 +++++------
net/core/fib_rules.c | 4 +-
net/ipv6/addrconf.c | 4 +-
net/wireless/reg.c | 1 +
net/wireless/sme.c | 2 +
net/xfrm/xfrm_input.c | 5 +++
22 files changed, 165 insertions(+), 80 deletions(-)
^ permalink raw reply
* Re: e1000e: NIC not working, power management issue?
From: Frederik Himpe @ 2011-09-21 20:57 UTC (permalink / raw)
To: jeffrey.t.kirsher, linux-kernel, netdev
Cc: e1000-devel@lists.sourceforge.net, Lucas Nussbaum, Ronciak, John,
Brandeburg, Jesse, John Ronciak
In-Reply-To: <1316598051.2182.48.camel@jtkirshe-mobl>
On Wed, 2011-09-21 at 02:40 -0700, Jeff Kirsher wrote:
> On Tue, 2011-09-20 at 12:03 -0700, Frederik Himpe wrote:
> > On Sun, 2011-09-18 at 18:04 +0200, Frederik Himpe wrote:
> > > On Sun, 2011-09-18 at 17:38 +0200, Frederik Himpe wrote:
> > >
> > > > I also tried some older Debian kernels and 2.6.34-1~experimental.2 is
> > > > working fine, while 2.6.35-1~experimental.3 (and later kernels I tried)
> > > > is broken, so I guess the problem started between 2.6.34 and 2.6.35.
> > > > Maybe I'll try to bisect now...
> > >
> > > Apparently these old kernels do not build anymore with my recent
> > > toolchain:
> > >
> > > AS arch/x86/kernel/entry_64.o
> > > /tmp/ccksyA7i.s: Assembler messages:
> > > /tmp/ccksyA7i.s: Error: .size expression for do_hypervisor_callback does
> > > not evaluate to a constant
> > >
> > > So I'm stuck here.
> >
> > Any further thing we can do to help this problem getting fixed?
> >
>
> You noted that the problem started between 2.6.34 and 2.6.35, and that
> you were going to try and bisect to find the "problem" patch. How is
> that effort coming along?
I cannot successfully build these kernels with my toolchain (see above).
> It also appears that you copied netdev and lkml on the original email,
> but they appear to have been dropped from the CC earlier on in this
> email discussion. It sounds like it would be prudent to add lkml &
> netdev back on to the email thread with what Jesse & John have suggested
> and seen based on the information provided. This way the power
> management maintainers are aware of the issue and potentially suggest
> other possible fix(es) that have not already been suggested.
Added these lists again.
To resume what we have found up to now: when runtime PM is activated for
the e1000e NIC, it does not wake up when a cable is plugged or when
ethtool is run. Runtime PM has to be deactivated to get the NIC working
again. Apparently this problem started between 2.6.34 and 2.6.35.
--
Frederik Himpe <fhimpe@telenet.be>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
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
* MTU and TCP transmit offload.
From: Ben Greear @ 2011-09-21 21:06 UTC (permalink / raw)
To: netdev
We saw something interesting while doing some testing
on 3.0.4.
We configured 2 Ethernet NICs with standard 1500 MTU, and added
a mac-vlan on each, with MTU of 300. The goal was to generate as
many ~300 byte TCP packets as possible, for load testing purposes.
We configured our tool to open sockets on the mac-vlans and send/receive
TCP (IPv4) traffic.
This actually seems to work quite nicely, allowing user-space to
do large writes (24k in our case), and it appears have lots of
small packets on the wire. We still need to sniff with external
system to verify this..but packets-per-second counters look good.
Evidently this all works because macvlans know that the NIC
can do TSO, and the '300' MTU is passed in the big packet
given to the NIC.
This got me thinking...at least for my purposes, it would be
nice to have a per-socket 'MTU' setting. The idea is that
you could ask the NIC to do the TSO at whatever 'mtu' you
wanted, without having to resort to mac-vlans with artificially
small MTU.
So, is there any interest in supporting such a socket option?
I can't think of any use besides TCP traffic load testing, but
perhaps someone else can think of one? Or, is load-testing
enough?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: MTU and TCP transmit offload.
From: Rick Jones @ 2011-09-21 22:11 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4E7A51EE.8010403@candelatech.com>
On 09/21/2011 02:06 PM, Ben Greear wrote:
> We saw something interesting while doing some testing
> on 3.0.4.
>
> We configured 2 Ethernet NICs with standard 1500 MTU, and added
> a mac-vlan on each, with MTU of 300. The goal was to generate as
> many ~300 byte TCP packets as possible, for load testing purposes.
> We configured our tool to open sockets on the mac-vlans and send/receive
> TCP (IPv4) traffic.
Presumably one could instead set static PathMTU entries in the routing
tables and accomplish the same thing as you did with the mac-vlans?
> This actually seems to work quite nicely, allowing user-space to
> do large writes (24k in our case), and it appears have lots of
> small packets on the wire. We still need to sniff with external
> system to verify this..but packets-per-second counters look good.
>
> Evidently this all works because macvlans know that the NIC
> can do TSO, and the '300' MTU is passed in the big packet
> given to the NIC.
>
> This got me thinking...at least for my purposes, it would be
> nice to have a per-socket 'MTU' setting. The idea is that
> you could ask the NIC to do the TSO at whatever 'mtu' you
> wanted, without having to resort to mac-vlans with artificially
> small MTU.
>
> So, is there any interest in supporting such a socket option?
>
> I can't think of any use besides TCP traffic load testing, but
> perhaps someone else can think of one? Or, is load-testing
> enough?
Isn't that covered by setsockopt() support for TCP_MAX_SEG? With TSO
what gets passed to the NIC isn't the MTU, but the connection's MSS
derived (in part at least) from the MTU of the egress interface. If one
had made a setsockopt(TCP_MAX_SEG) call prior to the connect() or
listen() call, presumably that would have influenced the MSS exchange at
connection establishment.
rick jones
^ 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