* Re: Problem with ARP-replies on Kernels 2.6 (possibly 3.0, but not 2.4!)
From: Nicolas de Pesloüan @ 2011-09-29 21:43 UTC (permalink / raw)
To: skandranon, netdev@vger.kernel.org
In-Reply-To: <4E8390E4.7080104@gmx.at>
Le 28/09/2011 23:25, skandranon a écrit :
>>> So: Is this a bug or a feature?
>>
>> It is a feature.
>>
>> You should have a look at the file Documentation/networking/ip-sysctl in the kernel source tree,
>> in particular the entry about arp_ignore.
>>
>> Nicolas.
> Many thanks for your quick reply and the pointer to that document.
Please, keep netdev in copy.
> Seems this feature has been there a long time already, but this has been the first time in all of
> the 15 years or so I'm working with Linux that It's bitten my ass.
>
> May I ask you for an additional pointer explaining in layman's terms what the use cases for values 2
> and 3 would be? - I plain don't understand.
2 seems obvious and is one more level of strictness. If the ARP seems to come from a different
subnet, ignore it, even if it enters the host on the "right" interface.
I don't know for 3.
> And maybe even an explanation what the initial reasoning might have been to select the approach of
> assigning IP addresses to the host instead of an interface?
I think it is expected to enhance connectivity, by being liberal at what the host accept, which is
the base principle of interoperability : Be liberal in what you accept, and conservative in what you
send [Jon Postel]. Others may explain this with more history in mind.
> The mailing list archive mentioned in e.g. "Understanding Linux Network Internals" I found after
> having your hint as a starting point doesn't seem to contain this discussion, which has obviously
> been old even back in 2003.
> And how come that the 2.4.21 kernel did behave differently? The basics seem to be the same?
Unfortunately, I'm not an archaeologist, so I'm totally unable to answer about 2.4.21. Maybe someone
else in the list will be.
Nicolas.
^ permalink raw reply
* Re: [PATCH v2 1/3] netdev/of/phy: New function: of_mdio_find_bus().
From: Grant Likely @ 2011-09-29 21:41 UTC (permalink / raw)
To: David Daney; +Cc: devicetree-discuss, linux-kernel, netdev, davem
In-Reply-To: <1317166015-20714-2-git-send-email-david.daney@cavium.com>
On Tue, Sep 27, 2011 at 04:26:53PM -0700, David Daney wrote:
> Add of_mdio_find_bus() which allows an mii_bus to be located given its
> associated the device tree node.
>
> This is needed by the follow-on patch to add a driver for MDIO bus
> multiplexers.
>
> The of_mdiobus_register() function is modified so that the device tree
> node is recorded in the mii_bus. Then we can find it again by
> iterating over all mdio_bus_class devices.
>
> Signed-off-by: David Daney <david.daney@cavium.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: "David S. Miller" <davem@davemloft.net>
> ---
> drivers/net/phy/mdio_bus.c | 3 ++-
> drivers/of/of_mdio.c | 26 ++++++++++++++++++++++++++
> include/linux/of_mdio.h | 2 ++
> include/linux/phy.h | 1 +
> 4 files changed, 31 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 6c58da2..227a060 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -70,10 +70,11 @@ static void mdiobus_release(struct device *d)
> kfree(bus);
> }
>
> -static struct class mdio_bus_class = {
> +struct class mdio_bus_class = {
> .name = "mdio_bus",
> .dev_release = mdiobus_release,
> };
> +EXPORT_SYMBOL(mdio_bus_class);
Instead of exporting this, move the iterator into this file. Assuming
Andy and David are okay with it, I don't see any reason to continue to
keep the MDIO DT support outside of drivers/net/phy.
Bonus points if you craft a patch to move the existing MDIO DT
support code.
Otherwise, the patch looks good.
g.
>
> /**
> * mdiobus_register - bring up all the PHYs on a given bus and attach them to bus
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index d35e300..7c28e8c 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -45,6 +45,8 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
> for (i=0; i<PHY_MAX_ADDR; i++)
> mdio->irq[i] = PHY_POLL;
>
> + mdio->dev.of_node = np;
> +
> /* Register the MDIO bus */
> rc = mdiobus_register(mdio);
> if (rc)
> @@ -189,3 +191,27 @@ struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
> return IS_ERR(phy) ? NULL : phy;
> }
> EXPORT_SYMBOL(of_phy_connect_fixed_link);
> +
> +/**
> + * of_mdio_find_bus - Given an mii_bus node, find the mii_bus.
> + * @mdio_np: Pointer to the mii_bus.
> + *
> + * Returns a pointer to the mii_bus, or NULL if none found.
> + *
> + * Because the association of a device_node and mii_bus is made via
> + * of_mdiobus_register(), the mii_bus cannot be found before it is
> + * registered with of_mdiobus_register().
> + *
> + */
> +struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np)
> +{
> + struct device *d;
> +
> + if (!mdio_np)
> + return NULL;
> +
> + d = class_find_device(&mdio_bus_class, NULL, mdio_np, of_phy_match);
> +
> + return d ? to_mii_bus(d) : NULL;
> +}
> +EXPORT_SYMBOL(of_mdio_find_bus);
> diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
> index 53b94e0..912c27a 100644
> --- a/include/linux/of_mdio.h
> +++ b/include/linux/of_mdio.h
> @@ -22,4 +22,6 @@ extern struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
> void (*hndlr)(struct net_device *),
> phy_interface_t iface);
>
> +extern struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np);
> +
> #endif /* __LINUX_OF_MDIO_H */
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index 54fc413..e4c3844 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -528,4 +528,5 @@ int __init mdio_bus_init(void);
> void mdio_bus_exit(void);
>
> extern struct bus_type mdio_bus_type;
> +extern struct class mdio_bus_class;
> #endif /* __PHY_H */
> --
> 1.7.2.3
>
^ permalink raw reply
* Re: [net-next 1/9] igb: Update RXDCTL/TXDCTL configurations
From: Alexander Duyck @ 2011-09-29 21:29 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: Jeff Kirsher, davem, netdev, gospo
In-Reply-To: <CACqU3MV64hahK0s7nDqNaRemZiygq33BgaY6_v9hh0iKX42Mfw@mail.gmail.com>
This is due to a HW errata. Specifically HW errata 26 in the spec
update at
http://download.intel.com/design/network/specupdt/82576_SPECUPDATE.pdf.
It essentially states that write back does not occur on MSI-X interrupt
events so we need to keep WTHRESH at 1 in order to avoid any false hangs.
Thanks,
Alex
On 09/29/2011 10:41 AM, Arnaud Lacombe wrote:
> Hi,
>
> On Tue, Sep 20, 2011 at 3:11 AM, Jeff Kirsher
> <jeffrey.t.kirsher@intel.com> wrote:
>> From: Alexander Duyck<alexander.h.duyck@intel.com>
>>
>> This change cleans up the RXDCTL and TXDCTL configurations and optimizes RX
>> performance by allowing back write-backs on all hardware other than 82576.
>>
> Where does this limitation comes from ? The "Intel 82576EB GbE
> Controller - Programming Interface" from May 2011 advertises that both
> the RXDCTL and TXDCTL register have a 5bit wide WTHRESH field.
>
> Thanks,
> - Arnaud
>
>> Signed-off-by: Alexander Duyck<alexander.h.duyck@intel.com>
>> Tested-by: Aaron Brown<aaron.f.brown@intel.com>
>> Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
>> ---
>> drivers/net/ethernet/intel/igb/igb.h | 5 +++--
>> drivers/net/ethernet/intel/igb/igb_main.c | 23 +++++++++--------------
>> 2 files changed, 12 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
>> index 265e151..577fd3e 100644
>> --- a/drivers/net/ethernet/intel/igb/igb.h
>> +++ b/drivers/net/ethernet/intel/igb/igb.h
>> @@ -100,11 +100,12 @@ struct vf_data_storage {
>> */
>> #define IGB_RX_PTHRESH 8
>> #define IGB_RX_HTHRESH 8
>> -#define IGB_RX_WTHRESH 1
>> #define IGB_TX_PTHRESH 8
>> #define IGB_TX_HTHRESH 1
>> +#define IGB_RX_WTHRESH ((hw->mac.type == e1000_82576&& \
>> + adapter->msix_entries) ? 1 : 4)
>> #define IGB_TX_WTHRESH ((hw->mac.type == e1000_82576&& \
>> - adapter->msix_entries) ? 1 : 16)
>> + adapter->msix_entries) ? 1 : 16)
>>
>> /* this is the size past which hardware will drop packets when setting LPE=0 */
>> #define MAXIMUM_ETHERNET_VLAN_SIZE 1522
>> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
>> index 3cb1bc9..aa78c10 100644
>> --- a/drivers/net/ethernet/intel/igb/igb_main.c
>> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
>> @@ -2666,14 +2666,12 @@ void igb_configure_tx_ring(struct igb_adapter *adapter,
>> struct igb_ring *ring)
>> {
>> struct e1000_hw *hw =&adapter->hw;
>> - u32 txdctl;
>> + u32 txdctl = 0;
>> u64 tdba = ring->dma;
>> int reg_idx = ring->reg_idx;
>>
>> /* disable the queue */
>> - txdctl = rd32(E1000_TXDCTL(reg_idx));
>> - wr32(E1000_TXDCTL(reg_idx),
>> - txdctl& ~E1000_TXDCTL_QUEUE_ENABLE);
>> + wr32(E1000_TXDCTL(reg_idx), 0);
>> wrfl();
>> mdelay(10);
>>
>> @@ -2685,7 +2683,7 @@ void igb_configure_tx_ring(struct igb_adapter *adapter,
>>
>> ring->head = hw->hw_addr + E1000_TDH(reg_idx);
>> ring->tail = hw->hw_addr + E1000_TDT(reg_idx);
>> - writel(0, ring->head);
>> + wr32(E1000_TDH(reg_idx), 0);
>> writel(0, ring->tail);
>>
>> txdctl |= IGB_TX_PTHRESH;
>> @@ -3028,12 +3026,10 @@ void igb_configure_rx_ring(struct igb_adapter *adapter,
>> struct e1000_hw *hw =&adapter->hw;
>> u64 rdba = ring->dma;
>> int reg_idx = ring->reg_idx;
>> - u32 srrctl, rxdctl;
>> + u32 srrctl = 0, rxdctl = 0;
>>
>> /* disable the queue */
>> - rxdctl = rd32(E1000_RXDCTL(reg_idx));
>> - wr32(E1000_RXDCTL(reg_idx),
>> - rxdctl& ~E1000_RXDCTL_QUEUE_ENABLE);
>> + wr32(E1000_RXDCTL(reg_idx), 0);
>>
>> /* Set DMA base address registers */
>> wr32(E1000_RDBAL(reg_idx),
>> @@ -3045,7 +3041,7 @@ void igb_configure_rx_ring(struct igb_adapter *adapter,
>> /* initialize head and tail */
>> ring->head = hw->hw_addr + E1000_RDH(reg_idx);
>> ring->tail = hw->hw_addr + E1000_RDT(reg_idx);
>> - writel(0, ring->head);
>> + wr32(E1000_RDH(reg_idx), 0);
>> writel(0, ring->tail);
>>
>> /* set descriptor configuration */
>> @@ -3076,13 +3072,12 @@ void igb_configure_rx_ring(struct igb_adapter *adapter,
>> /* set filtering for VMDQ pools */
>> igb_set_vmolr(adapter, reg_idx& 0x7, true);
>>
>> - /* enable receive descriptor fetching */
>> - rxdctl = rd32(E1000_RXDCTL(reg_idx));
>> - rxdctl |= E1000_RXDCTL_QUEUE_ENABLE;
>> - rxdctl&= 0xFFF00000;
>> rxdctl |= IGB_RX_PTHRESH;
>> rxdctl |= IGB_RX_HTHRESH<< 8;
>> rxdctl |= IGB_RX_WTHRESH<< 16;
>> +
>> + /* enable receive descriptor fetching */
>> + rxdctl |= E1000_RXDCTL_QUEUE_ENABLE;
>> wr32(E1000_RXDCTL(reg_idx), rxdctl);
>> }
>>
>> --
>> 1.7.6.2
>>
>> --
>> 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
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: linux-next: manual merge of the moduleh tree with the net tree
From: Paul Gortmaker @ 2011-09-29 20:47 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Pavel Roskin, John W. Linville,
David Miller, netdev
In-Reply-To: <20110928163406.843e4be56b42dca280d85489@canb.auug.org.au>
[linux-next: manual merge of the moduleh tree with the net tree] On 28/09/2011 (Wed 16:34) Stephen Rothwell wrote:
> Hi Paul,
>
> Today's linux-next merge of the moduleh tree got a conflict in
> drivers/net/wireless/ath/ath5k/debug.c between commit 931be260ed54
> ("ath5k: clean up base.h and its use") from the net tree and commits
> 9ec3f961e31a ("drivers/net: Add export.h to files using
> EXPORT_SYMBOL/THIS_MODULE") and 0cccb17382f1 ("drivers/net: Add
> moduleparam.h to drivers as required") from the moduleh tree.
>
> I fixed it up (see below) and can carry the fix as necessary. (I am
> pretty sure that this file doesn't need module.h, but not completely).
The conflict is gone, but you were correct in your original assessment
that the module.h was no longer needed. I've added this to the
post-merge queue of patches.
Thanks,
Paul.
>From 13a6768b382b3d2f96b9caa9fa6df1f2f7f3aeb6 Mon Sep 17 00:00:00 2001
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Thu, 29 Sep 2011 16:37:30 -0400
Subject: [PATCH] drivers/net: wireless/ath/ath5k/debug.c does not need
module.h
It only has module_param and EXPORT_SYMBOL, so now that export.h
is in scope at the same time as the recent ath5k update, we can
delete this module.h include.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
diff --git a/drivers/net/wireless/ath/ath5k/debug.c b/drivers/net/wireless/ath/ath5k/debug.c
index d2bdd90..f542b41 100644
--- a/drivers/net/wireless/ath/ath5k/debug.c
+++ b/drivers/net/wireless/ath/ath5k/debug.c
@@ -59,8 +59,6 @@
*/
#include <linux/export.h>
#include <linux/moduleparam.h>
-
-#include <linux/module.h>
#include <linux/seq_file.h>
#include <linux/list.h>
#include "debug.h"
--
1.7.6
^ permalink raw reply related
* Re: [PATCH v2 0/3] netdev/of/phy: MDIO bus multiplexer support.
From: David Miller @ 2011-09-29 20:31 UTC (permalink / raw)
To: david.daney; +Cc: devicetree-discuss, grant.likely, linux-kernel, netdev
In-Reply-To: <1317166015-20714-1-git-send-email-david.daney@cavium.com>
From: David Daney <david.daney@cavium.com>
Date: Tue, 27 Sep 2011 16:26:52 -0700
> v2: Update bindings to use "reg" and "mdio-parent-bus" insutead of
> "cell-index" and "parent-bus"
Grant, when the final version of this patch set is ready how do
you want to handle merging it in?
I think it would be safe to merge this via your tree, since the
changes made to existing network driver files are rather trivial and
thus merge conflict friendly.
Actually, I feel like we've discussed this before :-)
^ permalink raw reply
* Re: [net-next 0/8][pull request] Intel Wired LAN Drivers Update
From: David Miller @ 2011-09-29 19:48 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo
In-Reply-To: <1317277816-6024-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 28 Sep 2011 23:30:08 -0700
> The following series contains updates to e1000, ixgbe and ixgbevf. This
> series is missing the if_link and ixgbe patches for the additional
> parameter for spoof checking, since Greg is re-working those patches
> currently.
>
> The following are changes since commit 2e1143742789463c00ed5e7f9bf471f2b707b493:
> candev: allow SJW user setting for bittiming calculation
> and are available in the git repository at:
> git://github.com/Jkirsher/net-next.git
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net/stable] can bcm: fix incomplete tx_setup fix
From: David Miller @ 2011-09-29 19:38 UTC (permalink / raw)
To: socketcan; +Cc: netdev, stable, nautsch
In-Reply-To: <4E84C4B9.7020706@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Thu, 29 Sep 2011 21:19:21 +0200
> The commit aabdcb0b553b9c9547b1a506b34d55a764745870 ("can bcm: fix tx_setup
> off-by-one errors") fixed only a part of the original problem reported by
> Andre Naujoks. It turned out that the original code needed to be re-ordered
> to reduce complexity and to finally fix the reported frame counting issues.
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net-proc: expose the tos values in /proc/net/[tcp|udp]
From: David Miller @ 2011-09-29 19:32 UTC (permalink / raw)
To: muralira; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1317324162-21621-1-git-send-email-muralira@google.com>
From: Muraliraja Muniraju <muralira@google.com>
Date: Thu, 29 Sep 2011 12:22:42 -0700
> From: Murali Raja <muralira@google.com>
>
> This patch exports the tos values from the inet_sock struct
> for tcp and udp into the /proc/net/tcp or /proc/net/udp respectively.
> This will not pickup per packet tos changes but it will address most
> of the cases. This is mainly useful as it would decrease reliance on
> tcpdump and also people without root access will be able to read
> the values.
>
> Signed-off-by: Murali Raja <muralira@google.com>
You cannot change the layout of these files, they are parsed by userland
problems and therefore have a fixed API.
Netlink based socket dumping provides a proper, backwards compatible,
way to extend what is reported, so please consider adding your changes
there.
^ permalink raw reply
* [PATCH net/stable] can bcm: fix incomplete tx_setup fix
From: Oliver Hartkopp @ 2011-09-29 19:19 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, stable, Andre Naujoks
The commit aabdcb0b553b9c9547b1a506b34d55a764745870 ("can bcm: fix tx_setup
off-by-one errors") fixed only a part of the original problem reported by
Andre Naujoks. It turned out that the original code needed to be re-ordered
to reduce complexity and to finally fix the reported frame counting issues.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
@Andre: I checked the changes (which make the code much clearer now) against
your test program and some of mine i modified to test all flags like
STARTTIMER, SETTIMER, TX_ANNOUNCE in different configurations. Please double
check with your setup and send a Tested-by: if it is ok for you.
@Dave: Again sorry for this second patch. The first patch looked sane and
fixed the reported issue - but obviously not the whole problem :-(
bcm.c | 48 +++++++++++++++++++++---------------------------
1 file changed, 21 insertions(+), 27 deletions(-)
diff --git a/net/can/bcm.c b/net/can/bcm.c
index c9cdb8d..c84963d 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -344,6 +344,18 @@ static void bcm_send_to_user(struct bcm_op *op, struct bcm_msg_head *head,
}
}
+static void bcm_tx_start_timer(struct bcm_op *op)
+{
+ if (op->kt_ival1.tv64 && op->count)
+ hrtimer_start(&op->timer,
+ ktime_add(ktime_get(), op->kt_ival1),
+ HRTIMER_MODE_ABS);
+ else if (op->kt_ival2.tv64)
+ hrtimer_start(&op->timer,
+ ktime_add(ktime_get(), op->kt_ival2),
+ HRTIMER_MODE_ABS);
+}
+
static void bcm_tx_timeout_tsklet(unsigned long data)
{
struct bcm_op *op = (struct bcm_op *)data;
@@ -365,23 +377,12 @@ static void bcm_tx_timeout_tsklet(unsigned long data)
bcm_send_to_user(op, &msg_head, NULL, 0);
}
-
- /* send (next) frame */
bcm_can_tx(op);
- hrtimer_start(&op->timer,
- ktime_add(ktime_get(), op->kt_ival1),
- HRTIMER_MODE_ABS);
- } else {
- if (op->kt_ival2.tv64) {
+ } else if (op->kt_ival2.tv64)
+ bcm_can_tx(op);
- /* send (next) frame */
- bcm_can_tx(op);
- hrtimer_start(&op->timer,
- ktime_add(ktime_get(), op->kt_ival2),
- HRTIMER_MODE_ABS);
- }
- }
+ bcm_tx_start_timer(op);
}
/*
@@ -961,28 +962,21 @@ static int bcm_tx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
hrtimer_cancel(&op->timer);
}
- if ((op->flags & STARTTIMER) &&
- ((op->kt_ival1.tv64 && op->count) || op->kt_ival2.tv64)) {
-
+ if (op->flags & STARTTIMER) {
+ hrtimer_cancel(&op->timer);
/* spec: send can_frame when starting timer */
op->flags |= TX_ANNOUNCE;
-
- /* only start timer when having more frames than sent below */
- if (op->kt_ival1.tv64 && (op->count > 1)) {
- /* op->count-- is done in bcm_tx_timeout_tsklet */
- hrtimer_start(&op->timer, op->kt_ival1,
- HRTIMER_MODE_REL);
- } else
- hrtimer_start(&op->timer, op->kt_ival2,
- HRTIMER_MODE_REL);
}
if (op->flags & TX_ANNOUNCE) {
bcm_can_tx(op);
- if (op->kt_ival1.tv64 && (op->count > 0))
+ if (op->count)
op->count--;
}
+ if (op->flags & STARTTIMER)
+ bcm_tx_start_timer(op);
+
return msg_head->nframes * CFSIZ + MHSIZ;
}
^ permalink raw reply related
* [PATCH] net-proc: expose the tos values in /proc/net/[tcp|udp]
From: Muraliraja Muniraju @ 2011-09-29 19:22 UTC (permalink / raw)
To: David S. Miller", Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy <ka
Cc: netdev, linux-kernel, Murali Raja
From: Murali Raja <muralira@google.com>
This patch exports the tos values from the inet_sock struct
for tcp and udp into the /proc/net/tcp or /proc/net/udp respectively.
This will not pickup per packet tos changes but it will address most
of the cases. This is mainly useful as it would decrease reliance on
tcpdump and also people without root access will be able to read
the values.
Signed-off-by: Murali Raja <muralira@google.com>
---
net/ipv4/tcp_ipv4.c | 7 +++++--
net/ipv4/udp.c | 5 +++--
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index dd3fad9..b036184 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -2416,6 +2416,7 @@ static void get_tcp4_sock(struct sock *sk, struct seq_file *f, int i, int *len)
__u16 destp = ntohs(inet->inet_dport);
__u16 srcp = ntohs(inet->inet_sport);
int rx_queue;
+ unsigned int tos;
if (icsk->icsk_pending == ICSK_TIME_RETRANS) {
timer_active = 1;
@@ -2439,8 +2440,10 @@ static void get_tcp4_sock(struct sock *sk, struct seq_file *f, int i, int *len)
*/
rx_queue = max_t(int, tp->rcv_nxt - tp->copied_seq, 0);
+ tos = inet->tos;
+
seq_printf(f, "%4d: %08X:%04X %08X:%04X %02X %08X:%08X %02X:%08lX "
- "%08X %5d %8d %lu %d %pK %lu %lu %u %u %d%n",
+ "%08X %5d %8d %lu %d %pK %lu %lu %u %u %d %u%n",
i, src, srcp, dest, destp, sk->sk_state,
tp->write_seq - tp->snd_una,
rx_queue,
@@ -2455,7 +2458,7 @@ static void get_tcp4_sock(struct sock *sk, struct seq_file *f, int i, int *len)
jiffies_to_clock_t(icsk->icsk_ack.ato),
(icsk->icsk_ack.quick << 1) | icsk->icsk_ack.pingpong,
tp->snd_cwnd,
- tcp_in_initial_slowstart(tp) ? -1 : tp->snd_ssthresh,
+ tcp_in_initial_slowstart(tp) ? -1 : tp->snd_ssthresh, tos,
len);
}
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index ebaa96b..588786e 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -2092,15 +2092,16 @@ static void udp4_format_sock(struct sock *sp, struct seq_file *f,
__be32 src = inet->inet_rcv_saddr;
__u16 destp = ntohs(inet->inet_dport);
__u16 srcp = ntohs(inet->inet_sport);
+ unsigned int tos = inet->tos;
seq_printf(f, "%5d: %08X:%04X %08X:%04X"
- " %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %pK %d%n",
+ " %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %pK %d %d%n",
bucket, src, srcp, dest, destp, sp->sk_state,
sk_wmem_alloc_get(sp),
sk_rmem_alloc_get(sp),
0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
atomic_read(&sp->sk_refcnt), sp,
- atomic_read(&sp->sk_drops), len);
+ atomic_read(&sp->sk_drops), tos, len);
}
int udp4_seq_show(struct seq_file *seq, void *v)
--
1.7.3.1
^ permalink raw reply related
* Re: Question about memory leak detector giving false positive report for net/core/flow.c
From: Tejun Heo @ 2011-09-29 19:07 UTC (permalink / raw)
To: Catalin Marinas
Cc: Christoph Lameter, Eric Dumazet, Huajun Li, linux-mm@kvack.org,
netdev, linux-kernel
In-Reply-To: <20110929141809.GD32023@e102109-lin.cambridge.arm.com>
On Thu, Sep 29, 2011 at 03:18:10PM +0100, Catalin Marinas wrote:
> On Thu, Sep 29, 2011 at 03:08:47PM +0100, Christoph Lameter wrote:
> > On Wed, 28 Sep 2011, Catalin Marinas wrote:
> >
> > > I tried this but it's tricky. The problem is that the percpu pointer
> > > returned by alloc_percpu() does not directly point to the per-cpu chunks
> > > and kmemleak would report most percpu allocations as leaks. So far the
> > > workaround is to simply mark the alloc_percpu() objects as never leaking
> > > and at least we avoid false positives in other areas. See the patch
> > > below (note that you have to increase the CONFIG_KMEMLEAK_EARLY_LOG_SIZE
> > > as there are many alloc_percpu() calls before kmemleak is fully
> > > initialised):
> >
> > Seems that kernel.org is out and so tejon wont be seeing these.
>
> That's ok, I don't aim this at the upcoming merging window. I don't have
> an alternative email address for him.
That's htejun@gmail.com but as long as lkml is cc'd I can read the
emails. Lack of replies is more due to the month long vacation which
just ended. ;)
Thank you.
--
tejun
--
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: [PATCH] RDSRDMA: Fix cleanup of rds_iw_mr_pool
From: David Miller @ 2011-09-29 18:57 UTC (permalink / raw)
To: jonathan; +Cc: venkat.x.venkatsubra, netdev
In-Reply-To: <20110929175841.17682.27846.stgit@build.ogc.int>
From: Jonathan Lallinger <jonathan@ogc.us>
Date: Thu, 29 Sep 2011 12:58:41 -0500
> In the rds_iw_mr_pool struct the free_pinned field keeps track of
> memory pinned by free MRs. While this field is incremented properly
> upon allocation, it is never decremented upon unmapping. This would
> cause the rds_rdma module to crash the kernel upon unloading, by
> triggering the BUG_ON in the rds_iw_destroy_mr_pool function.
>
> This change keeps track of the MRs that become unpinned, so that
> free_pinned can be decremented appropriately.
>
> Signed-off-by: Jonathan Lallinger <jonathan@ogc.us>
> Signed-off-by: Steve Wise <swise@ogc.us>
Applied.
^ permalink raw reply
* Re: [PATCH] net: Documentation: Fix type of variables
From: David Miller @ 2011-09-29 18:57 UTC (permalink / raw)
To: rongqing.li; +Cc: netdev
In-Reply-To: <1317275514-12620-1-git-send-email-rongqing.li@windriver.com>
From: <rongqing.li@windriver.com>
Date: Thu, 29 Sep 2011 13:51:54 +0800
> From: Roy.Li <rongqing.li@windriver.com>
>
>
> Signed-off-by: Roy.Li <rongqing.li@windriver.com>
Applied.
^ permalink raw reply
* Re: [patch] usbnet: add timestamping support
From: David Miller @ 2011-09-29 18:55 UTC (permalink / raw)
To: michael; +Cc: netdev, oneukum
In-Reply-To: <1317305186-32700-1-git-send-email-michael@riesch.at>
From: Michael Riesch <michael@riesch.at>
Date: Thu, 29 Sep 2011 16:06:26 +0200
> In order to make USB-to-Ethernet-adapters (depending on usbnet) support
> timestamping, the "skb_defer_rx_timestamp" and "skb_tx_timestamp" function
> calls are added.
>
> Signed-off-by: Michael Riesch <michael@riesch.at>
Applied.
^ permalink raw reply
* Re: [PATCH v2 2/2] net/fec: add poll controller function for fec nic
From: David Miller @ 2011-09-29 18:54 UTC (permalink / raw)
To: jgq516; +Cc: netdev, linux-kernel
In-Reply-To: <1317298557-2878-2-git-send-email-jgq516@gmail.com>
From: jgq516@gmail.com
Date: Thu, 29 Sep 2011 20:15:57 +0800
> From: Xiao Jiang <jgq516@gmail.com>
>
> Add poll controller function for fec nic.
>
> Signed-off-by: Xiao Jiang <jgq516@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 1/2] net/fec: replace hardcoded irq num with macro
From: David Miller @ 2011-09-29 18:54 UTC (permalink / raw)
To: jgq516; +Cc: netdev, linux-kernel
In-Reply-To: <1317298557-2878-1-git-send-email-jgq516@gmail.com>
From: jgq516@gmail.com
Date: Thu, 29 Sep 2011 20:15:56 +0800
> From: Xiao Jiang <jgq516@gmail.com>
>
> Don't use hardcoded irq num and replace it with
> FEC_IRQ_NUM macro.
>
> Signed-off-by: Xiao Jiang <jgq516@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] RDSRDMA: Fix cleanup of rds_iw_mr_pool
From: Venkat Venkatsubra @ 2011-09-29 18:51 UTC (permalink / raw)
To: jonathan; +Cc: netdev, davem
In the rds_iw_mr_pool struct the free_pinned field keeps track of
memory pinned by free MRs. While this field is incremented properly
upon allocation, it is never decremented upon unmapping. This would
cause the rds_rdma module to crash the kernel upon unloading, by
triggering the BUG_ON in the rds_iw_destroy_mr_pool function.
This change keeps track of the MRs that become unpinned, so that
free_pinned can be decremented appropriately.
Signed-off-by: Jonathan Lallinger <jonathan@ogc.us>
Signed-off-by: Steve Wise <swise@ogc.us>
---
Signed-off-by: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Venkat
^ permalink raw reply
* [PATCH] RDSRDMA: Fix cleanup of rds_iw_mr_pool
From: Jonathan Lallinger @ 2011-09-29 17:58 UTC (permalink / raw)
To: davem, venkat.x.venkatsubra; +Cc: netdev
In the rds_iw_mr_pool struct the free_pinned field keeps track of
memory pinned by free MRs. While this field is incremented properly
upon allocation, it is never decremented upon unmapping. This would
cause the rds_rdma module to crash the kernel upon unloading, by
triggering the BUG_ON in the rds_iw_destroy_mr_pool function.
This change keeps track of the MRs that become unpinned, so that
free_pinned can be decremented appropriately.
Signed-off-by: Jonathan Lallinger <jonathan@ogc.us>
Signed-off-by: Steve Wise <swise@ogc.us>
---
net/rds/iw_rdma.c | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/net/rds/iw_rdma.c b/net/rds/iw_rdma.c
index 7c1c873..81d3167 100644
--- a/net/rds/iw_rdma.c
+++ b/net/rds/iw_rdma.c
@@ -84,7 +84,8 @@ static int rds_iw_map_fastreg(struct rds_iw_mr_pool *pool,
static void rds_iw_free_fastreg(struct rds_iw_mr_pool *pool, struct rds_iw_mr *ibmr);
static unsigned int rds_iw_unmap_fastreg_list(struct rds_iw_mr_pool *pool,
struct list_head *unmap_list,
- struct list_head *kill_list);
+ struct list_head *kill_list,
+ int *unpinned);
static void rds_iw_destroy_fastreg(struct rds_iw_mr_pool *pool, struct rds_iw_mr *ibmr);
static int rds_iw_get_device(struct rds_sock *rs, struct rds_iw_device **rds_iwdev, struct rdma_cm_id **cm_id)
@@ -499,7 +500,7 @@ static int rds_iw_flush_mr_pool(struct rds_iw_mr_pool *pool, int free_all)
LIST_HEAD(unmap_list);
LIST_HEAD(kill_list);
unsigned long flags;
- unsigned int nfreed = 0, ncleaned = 0, free_goal;
+ unsigned int nfreed = 0, ncleaned = 0, unpinned = 0, free_goal;
int ret = 0;
rds_iw_stats_inc(s_iw_rdma_mr_pool_flush);
@@ -524,7 +525,8 @@ static int rds_iw_flush_mr_pool(struct rds_iw_mr_pool *pool, int free_all)
* will be destroyed by the unmap function.
*/
if (!list_empty(&unmap_list)) {
- ncleaned = rds_iw_unmap_fastreg_list(pool, &unmap_list, &kill_list);
+ ncleaned = rds_iw_unmap_fastreg_list(pool, &unmap_list,
+ &kill_list, &unpinned);
/* If we've been asked to destroy all MRs, move those
* that were simply cleaned to the kill list */
if (free_all)
@@ -548,6 +550,7 @@ static int rds_iw_flush_mr_pool(struct rds_iw_mr_pool *pool, int free_all)
spin_unlock_irqrestore(&pool->list_lock, flags);
}
+ atomic_sub(unpinned, &pool->free_pinned);
atomic_sub(ncleaned, &pool->dirty_count);
atomic_sub(nfreed, &pool->item_count);
@@ -828,7 +831,8 @@ static void rds_iw_free_fastreg(struct rds_iw_mr_pool *pool,
static unsigned int rds_iw_unmap_fastreg_list(struct rds_iw_mr_pool *pool,
struct list_head *unmap_list,
- struct list_head *kill_list)
+ struct list_head *kill_list,
+ int *unpinned)
{
struct rds_iw_mapping *mapping, *next;
unsigned int ncleaned = 0;
@@ -855,6 +859,7 @@ static unsigned int rds_iw_unmap_fastreg_list(struct rds_iw_mr_pool *pool,
spin_lock_irqsave(&pool->list_lock, flags);
list_for_each_entry_safe(mapping, next, unmap_list, m_list) {
+ *unpinned += mapping->m_sg.len;
list_move(&mapping->m_list, &laundered);
ncleaned++;
}
^ permalink raw reply related
* Re: [net-next 1/9] igb: Update RXDCTL/TXDCTL configurations
From: Arnaud Lacombe @ 2011-09-29 17:41 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Alexander Duyck, netdev, gospo
In-Reply-To: <1316502690-25488-2-git-send-email-jeffrey.t.kirsher@intel.com>
Hi,
On Tue, Sep 20, 2011 at 3:11 AM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This change cleans up the RXDCTL and TXDCTL configurations and optimizes RX
> performance by allowing back write-backs on all hardware other than 82576.
>
Where does this limitation comes from ? The "Intel 82576EB GbE
Controller - Programming Interface" from May 2011 advertises that both
the RXDCTL and TXDCTL register have a 5bit wide WTHRESH field.
Thanks,
- Arnaud
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/ethernet/intel/igb/igb.h | 5 +++--
> drivers/net/ethernet/intel/igb/igb_main.c | 23 +++++++++--------------
> 2 files changed, 12 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
> index 265e151..577fd3e 100644
> --- a/drivers/net/ethernet/intel/igb/igb.h
> +++ b/drivers/net/ethernet/intel/igb/igb.h
> @@ -100,11 +100,12 @@ struct vf_data_storage {
> */
> #define IGB_RX_PTHRESH 8
> #define IGB_RX_HTHRESH 8
> -#define IGB_RX_WTHRESH 1
> #define IGB_TX_PTHRESH 8
> #define IGB_TX_HTHRESH 1
> +#define IGB_RX_WTHRESH ((hw->mac.type == e1000_82576 && \
> + adapter->msix_entries) ? 1 : 4)
> #define IGB_TX_WTHRESH ((hw->mac.type == e1000_82576 && \
> - adapter->msix_entries) ? 1 : 16)
> + adapter->msix_entries) ? 1 : 16)
>
> /* this is the size past which hardware will drop packets when setting LPE=0 */
> #define MAXIMUM_ETHERNET_VLAN_SIZE 1522
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
> index 3cb1bc9..aa78c10 100644
> --- a/drivers/net/ethernet/intel/igb/igb_main.c
> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> @@ -2666,14 +2666,12 @@ void igb_configure_tx_ring(struct igb_adapter *adapter,
> struct igb_ring *ring)
> {
> struct e1000_hw *hw = &adapter->hw;
> - u32 txdctl;
> + u32 txdctl = 0;
> u64 tdba = ring->dma;
> int reg_idx = ring->reg_idx;
>
> /* disable the queue */
> - txdctl = rd32(E1000_TXDCTL(reg_idx));
> - wr32(E1000_TXDCTL(reg_idx),
> - txdctl & ~E1000_TXDCTL_QUEUE_ENABLE);
> + wr32(E1000_TXDCTL(reg_idx), 0);
> wrfl();
> mdelay(10);
>
> @@ -2685,7 +2683,7 @@ void igb_configure_tx_ring(struct igb_adapter *adapter,
>
> ring->head = hw->hw_addr + E1000_TDH(reg_idx);
> ring->tail = hw->hw_addr + E1000_TDT(reg_idx);
> - writel(0, ring->head);
> + wr32(E1000_TDH(reg_idx), 0);
> writel(0, ring->tail);
>
> txdctl |= IGB_TX_PTHRESH;
> @@ -3028,12 +3026,10 @@ void igb_configure_rx_ring(struct igb_adapter *adapter,
> struct e1000_hw *hw = &adapter->hw;
> u64 rdba = ring->dma;
> int reg_idx = ring->reg_idx;
> - u32 srrctl, rxdctl;
> + u32 srrctl = 0, rxdctl = 0;
>
> /* disable the queue */
> - rxdctl = rd32(E1000_RXDCTL(reg_idx));
> - wr32(E1000_RXDCTL(reg_idx),
> - rxdctl & ~E1000_RXDCTL_QUEUE_ENABLE);
> + wr32(E1000_RXDCTL(reg_idx), 0);
>
> /* Set DMA base address registers */
> wr32(E1000_RDBAL(reg_idx),
> @@ -3045,7 +3041,7 @@ void igb_configure_rx_ring(struct igb_adapter *adapter,
> /* initialize head and tail */
> ring->head = hw->hw_addr + E1000_RDH(reg_idx);
> ring->tail = hw->hw_addr + E1000_RDT(reg_idx);
> - writel(0, ring->head);
> + wr32(E1000_RDH(reg_idx), 0);
> writel(0, ring->tail);
>
> /* set descriptor configuration */
> @@ -3076,13 +3072,12 @@ void igb_configure_rx_ring(struct igb_adapter *adapter,
> /* set filtering for VMDQ pools */
> igb_set_vmolr(adapter, reg_idx & 0x7, true);
>
> - /* enable receive descriptor fetching */
> - rxdctl = rd32(E1000_RXDCTL(reg_idx));
> - rxdctl |= E1000_RXDCTL_QUEUE_ENABLE;
> - rxdctl &= 0xFFF00000;
> rxdctl |= IGB_RX_PTHRESH;
> rxdctl |= IGB_RX_HTHRESH << 8;
> rxdctl |= IGB_RX_WTHRESH << 16;
> +
> + /* enable receive descriptor fetching */
> + rxdctl |= E1000_RXDCTL_QUEUE_ENABLE;
> wr32(E1000_RXDCTL(reg_idx), rxdctl);
> }
>
> --
> 1.7.6.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Question about memory leak detector giving false positive report for net/core/flow.c
From: Catalin Marinas @ 2011-09-29 14:18 UTC (permalink / raw)
To: Christoph Lameter
Cc: Eric Dumazet, Huajun Li, linux-mm@kvack.org, netdev, linux-kernel,
Tejun Heo
In-Reply-To: <alpine.DEB.2.00.1109290907450.9382@router.home>
On Thu, Sep 29, 2011 at 03:08:47PM +0100, Christoph Lameter wrote:
> On Wed, 28 Sep 2011, Catalin Marinas wrote:
>
> > I tried this but it's tricky. The problem is that the percpu pointer
> > returned by alloc_percpu() does not directly point to the per-cpu chunks
> > and kmemleak would report most percpu allocations as leaks. So far the
> > workaround is to simply mark the alloc_percpu() objects as never leaking
> > and at least we avoid false positives in other areas. See the patch
> > below (note that you have to increase the CONFIG_KMEMLEAK_EARLY_LOG_SIZE
> > as there are many alloc_percpu() calls before kmemleak is fully
> > initialised):
>
> Seems that kernel.org is out and so tejon wont be seeing these.
That's ok, I don't aim this at the upcoming merging window. I don't have
an alternative email address for him.
--
Catalin
--
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: Question about memory leak detector giving false positive report for net/core/flow.c
From: Christoph Lameter @ 2011-09-29 14:08 UTC (permalink / raw)
To: Catalin Marinas
Cc: Eric Dumazet, Huajun Li, linux-mm@kvack.org, netdev, linux-kernel,
Tejun Heo
In-Reply-To: <20110928172342.GH23559@e102109-lin.cambridge.arm.com>
On Wed, 28 Sep 2011, Catalin Marinas wrote:
> I tried this but it's tricky. The problem is that the percpu pointer
> returned by alloc_percpu() does not directly point to the per-cpu chunks
> and kmemleak would report most percpu allocations as leaks. So far the
> workaround is to simply mark the alloc_percpu() objects as never leaking
> and at least we avoid false positives in other areas. See the patch
> below (note that you have to increase the CONFIG_KMEMLEAK_EARLY_LOG_SIZE
> as there are many alloc_percpu() calls before kmemleak is fully
> initialised):
Seems that kernel.org is out and so tejon wont be seeing these.
--
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: [patch] usbnet: add timestamping support
From: Michael Riesch @ 2011-09-29 14:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev, oneukum
In-Reply-To: <20110928.032057.938343201578831873.davem@davemloft.net>
On Wed, 2011-09-28 at 03:20 -0400, David Miller wrote:
> Patch is severly corrupted by your email client.
>
> Correct this (see Documentation/email-clients.txt), send a test patch
> to yourself, and only resubmit this change when you can successfully
> apply a patch you send to youself.
Sorry about that. I switched to git-send-email and tested it. I hope it
works now.
Regards, Michael
^ permalink raw reply
* [patch] usbnet: add timestamping support
From: Michael Riesch @ 2011-09-29 14:06 UTC (permalink / raw)
To: netdev; +Cc: oneukum, davem, Michael Riesch
In order to make USB-to-Ethernet-adapters (depending on usbnet) support
timestamping, the "skb_defer_rx_timestamp" and "skb_tx_timestamp" function
calls are added.
Signed-off-by: Michael Riesch <michael@riesch.at>
---
drivers/net/usb/usbnet.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 2ab9b98..b57b57b 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -239,6 +239,10 @@ void usbnet_skb_return (struct usbnet *dev, struct sk_buff *skb)
netif_dbg(dev, rx_status, dev->net, "< rx, len %zu, type 0x%x\n",
skb->len + sizeof (struct ethhdr), skb->protocol);
memset (skb->cb, 0, sizeof (struct skb_data));
+
+ if (skb_defer_rx_timestamp(skb))
+ return;
+
status = netif_rx (skb);
if (status != NET_RX_SUCCESS)
netif_dbg(dev, rx_err, dev->net,
@@ -1071,6 +1075,8 @@ netdev_tx_t usbnet_start_xmit (struct sk_buff *skb,
unsigned long flags;
int retval;
+ skb_tx_timestamp(skb);
+
// some devices want funky USB-level framing, for
// win32 driver (usually) and/or hardware quirks
if (info->tx_fixup) {
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] net/flow: remove sleeping and deferral mechanism from flow_cache_flush
From: Benjamin Poirier @ 2011-09-29 13:24 UTC (permalink / raw)
To: Madalin Bucur; +Cc: eric.dumazet, netdev, davem, timo.teras
In-Reply-To: <1317056956-23644-1-git-send-email-madalin.bucur@freescale.com>
On 11-09-26 20:09, Madalin Bucur wrote:
> flow_cache_flush must not sleep as it can be called in atomic context;
> removed the schedule_work as the deferred processing lead to the flow
> cache gc never being actually run under heavy network load
>
> Signed-off-by: Madalin Bucur <madalin.bucur@freescale.com>
> ---
> net/core/flow.c | 21 +++++++++------------
> 1 files changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/net/core/flow.c b/net/core/flow.c
> index 555a456..0950f97 100644
> --- a/net/core/flow.c
> +++ b/net/core/flow.c
> @@ -14,7 +14,6 @@
> #include <linux/init.h>
> #include <linux/slab.h>
> #include <linux/smp.h>
> -#include <linux/completion.h>
> #include <linux/percpu.h>
> #include <linux/bitops.h>
> #include <linux/notifier.h>
> @@ -49,7 +48,6 @@ struct flow_cache_percpu {
> struct flow_flush_info {
> struct flow_cache *cache;
> atomic_t cpuleft;
> - struct completion completion;
> };
>
> struct flow_cache {
> @@ -100,7 +98,7 @@ static void flow_entry_kill(struct flow_cache_entry *fle)
> kmem_cache_free(flow_cachep, fle);
> }
>
> -static void flow_cache_gc_task(struct work_struct *work)
> +static void flow_cache_gc_task(void)
> {
> struct list_head gc_list;
> struct flow_cache_entry *fce, *n;
> @@ -113,7 +111,6 @@ static void flow_cache_gc_task(struct work_struct *work)
> list_for_each_entry_safe(fce, n, &gc_list, u.gc_list)
> flow_entry_kill(fce);
> }
> -static DECLARE_WORK(flow_cache_gc_work, flow_cache_gc_task);
>
> static void flow_cache_queue_garbage(struct flow_cache_percpu *fcp,
> int deleted, struct list_head *gc_list)
> @@ -123,7 +120,7 @@ static void flow_cache_queue_garbage(struct flow_cache_percpu *fcp,
> spin_lock_bh(&flow_cache_gc_lock);
> list_splice_tail(gc_list, &flow_cache_gc_list);
> spin_unlock_bh(&flow_cache_gc_lock);
> - schedule_work(&flow_cache_gc_work);
> + flow_cache_gc_task();
> }
> }
>
> @@ -320,8 +317,7 @@ static void flow_cache_flush_tasklet(unsigned long data)
>
> flow_cache_queue_garbage(fcp, deleted, &gc_list);
>
> - if (atomic_dec_and_test(&info->cpuleft))
> - complete(&info->completion);
> + atomic_dec(&info->cpuleft);
> }
>
> static void flow_cache_flush_per_cpu(void *data)
> @@ -339,22 +335,23 @@ static void flow_cache_flush_per_cpu(void *data)
> void flow_cache_flush(void)
> {
> struct flow_flush_info info;
> - static DEFINE_MUTEX(flow_flush_sem);
> + static DEFINE_SPINLOCK(flow_flush_lock);
>
> /* Don't want cpus going down or up during this. */
> get_online_cpus();
> - mutex_lock(&flow_flush_sem);
> + spin_lock_bh(&flow_flush_lock);
> info.cache = &flow_cache_global;
> atomic_set(&info.cpuleft, num_online_cpus());
> - init_completion(&info.completion);
>
> local_bh_disable();
local_bh_disable may as well be removed with the change to
spin_lock_bh() just above.
Also, I fail to see why bh_disable is needed for
flow_cache_flush_tasklet(). If you don't mind enlightening me, it'll be
appreciated.
Thanks,
-Ben
> smp_call_function(flow_cache_flush_per_cpu, &info, 0);
> flow_cache_flush_tasklet((unsigned long)&info);
> local_bh_enable();
>
> - wait_for_completion(&info.completion);
> - mutex_unlock(&flow_flush_sem);
> + while (atomic_read(&info.cpuleft) != 0)
> + cpu_relax();
> +
> + spin_unlock_bh(&flow_flush_lock);
> put_online_cpus();
> }
>
> --
> 1.7.0.1
>
>
> --
> 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
* Network problem with bridge and virtualbox
From: William Thompson @ 2011-09-29 12:49 UTC (permalink / raw)
To: netdev
Please keep me in the CC as I am not subscribed.
I'm using a 64-bit kernel 3.0.0 and virtualbox 4.1.2.
My problem is that I cannot ping the host from a virtual machine.
My bridge is configured as follows:
# brctl addbr br0
# brctl setfd br0 0
# brctl stp br0 off
# ifconfig br0 10.2.3.1 netmask 255.255.255.0
In the virtual machine, it is set to use br0 as it's interface (bridge mode)
and it's IP is 10.2.3.10.
The host gets packets from the vm, but the vm does not receive packets back.
I have this same setup working on a 32-bit kernel 2.6.38.6 on another
machine with virtualbox 4.0.4.
I had a thought that the bridge on the host wasn't responding due to having
no ports configured so I added one of my spare ethernet cards to it as
follows:
# brctl addif br0 eth1
# ifconfig eth1 up
The card was plugged into a switch. After doing this, the vm still could not
talk to the host. I added a physical machine to the switch that eth1 was
connected to and configured it to 10.2.3.2. I was able to ping 10.2.3.2 but
not 10.2.3.1
^ 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