* RE: [PATCH] ppp_generic: fix multilink fragment sizes
From: Paoloni, Gabriele @ 2010-06-02 15:17 UTC (permalink / raw)
To: Ben McKeegan, davem@davemloft.net
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
alan@lxorguk.ukuu.org.uk, linux-ppp@vger.kernel.org,
paulus@samba.org
In-Reply-To: <1275491094-9526-1-git-send-email-ben@netservers.co.uk>
The proposed patch looks wrong to me.
nbigger is already doing the job; I didn't use DIV_ROUND_UP because in general we don't have always to roundup, otherwise we would exceed the total bandwidth.
Regards
Gabriele Paoloni
-----Original Message-----
From: Ben McKeegan [mailto:ben@netservers.co.uk]
Sent: 02 June 2010 16:05
To: davem@davemloft.net
Cc: ben@netservers.co.uk; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Paoloni, Gabriele; alan@lxorguk.ukuu.org.uk; linux-ppp@vger.kernel.org; paulus@samba.org
Subject: [PATCH] ppp_generic: fix multilink fragment sizes
Fix bug in multilink fragment size calculation introduced by
commit 9c705260feea6ae329bc6b6d5f6d2ef0227eda0a
"ppp: ppp_mp_explode() redesign"
Signed-off-by: Ben McKeegan <ben@netservers.co.uk>
---
drivers/net/ppp_generic.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ppp_generic.c b/drivers/net/ppp_generic.c
index 0db3894..8b36bfe 100644
--- a/drivers/net/ppp_generic.c
+++ b/drivers/net/ppp_generic.c
@@ -1416,7 +1416,8 @@ static int ppp_mp_explode(struct ppp *ppp, struct sk_buff *skb)
flen = len;
if (nfree > 0) {
if (pch->speed == 0) {
- flen = totlen/nfree;
+ if (nfree > 1)
+ flen = DIV_ROUND_UP(len, nfree);
if (nbigger > 0) {
flen++;
nbigger--;
--
1.5.6.5
--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* Re: cls_u32: check unaligned data access
From: David Miller @ 2010-06-02 15:18 UTC (permalink / raw)
To: xiaosuo; +Cc: hadi, netdev
In-Reply-To: <1275491747-29888-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Wed, 2 Jun 2010 23:15:47 +0800
> check unaligned data access
>
> before accessing data, check if the corresponding address is aligned, and if
> not, return -1.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
The user will find out when he gets warnings in his kernel log
messages on platforms where this matters.
And, if anything, silently just skipping over things is not
acceptable. And imposing a 4-byte alignment could break
existing setups that actually work on x86 and powerpc which
are platforms that don't have alignment issues.
I basically tried to explain to you earlier that I wasn't going to
accept patches that try to deal with alignment in any way here in this
code, we explicitly and intentionally blindly dereference the data.
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Christoph Lameter @ 2010-06-02 15:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Stephen Hemminger, David Miller
In-Reply-To: <1275430054.2638.115.camel@edumazet-laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1665 bytes --]
On Wed, 2 Jun 2010, Eric Dumazet wrote:
> Le mardi 01 juin 2010 à 16:13 -0500, Christoph Lameter a écrit :
> > Something like this would have been very helpful during recent debugging
> > of multicast issues. Silent discards are bad.
> >
>
> >
> > If the kernel perceives that something is wrong with an incoming packet then the
> > IP stack currently silently discards packets. This makes it difficult to diagnose
> > problems with the network configurations (such as a misbehaving kernel
> > subsystem discarding multicast packets because the reverse path filter
> > does not like multicast subscriptions on the second NIC with rp_filter=1).
> >
> > It is also necessary to know how many inbound packets are discarded to
> > assess networking issues in general with a NIC.
> >
> > Signed-off-by: Christoph Lameter <cl@linux-foundation.org>
> > Acked-by: Stephen Hemminger <shemminger@vyatta.com>
> >
>
> I disagree with this patch.
>
> IPSTATS_MIB_INADDRERRORS has a strong meaning, part of RFCS.
>
> In this path, we simulate the routing of a virtual packet, not its
> delivery.
>
> This should not affect IPSTATS SNMP entries.
>
> You should use another MIB entry, say LINUX_MIB_INROUTEERRORS ?
>
> Dont inet_rtm_getroute() caller gets an error status anyway ?
Yes but they are not increment any counter. If packets are dropped because
of the rp_filter setting interfering f.e. then the packets vanish without
any accounting.
LINUX_MIB_INROUTEERRORS? Does it mean I can create a series of new
counters that allow us to diagnose and distinguish all the different
causes of packet loss? We would love to have that.
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: David Miller @ 2010-06-02 15:29 UTC (permalink / raw)
To: cl; +Cc: eric.dumazet, netdev, shemminger
In-Reply-To: <alpine.DEB.2.00.1006021025200.30182@router.home>
From: Christoph Lameter <cl@linux-foundation.org>
Date: Wed, 2 Jun 2010 10:27:13 -0500 (CDT)
> LINUX_MIB_INROUTEERRORS? Does it mean I can create a series of new
> counters that allow us to diagnose and distinguish all the different
> causes of packet loss? We would love to have that.
Within reason.
If you're going to spam the tree with something like 10 or 20 new
stat counters getting bumped all over the place, that's not what
we're trying to suggest here.
Consolidate as much as possible, add new things when absolutely
nothing existing fits the bill.
^ permalink raw reply
* [net-next PATCH] drivers/net/enic: Use (pr|netdev)_<level> macro helpers
From: Joe Perches @ 2010-06-02 15:30 UTC (permalink / raw)
To: Scott Feldman; +Cc: netdev, LKML
Compile tested only
Add #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
Remove #define PFX
Use pr_<level>
Use netdev_<level>
Remove trailing periods from most formats
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/enic/enic.h | 1 -
drivers/net/enic/enic_main.c | 120 ++++++++++++++++++------------------------
drivers/net/enic/enic_res.c | 51 +++++++++---------
drivers/net/enic/vnic_cq.c | 2 +-
drivers/net/enic/vnic_dev.c | 37 ++++++-------
drivers/net/enic/vnic_intr.c | 5 +-
drivers/net/enic/vnic_rq.c | 8 ++-
drivers/net/enic/vnic_wq.c | 8 ++-
8 files changed, 108 insertions(+), 124 deletions(-)
diff --git a/drivers/net/enic/enic.h b/drivers/net/enic/enic.h
index 85f2a2e..4277975 100644
--- a/drivers/net/enic/enic.h
+++ b/drivers/net/enic/enic.h
@@ -36,7 +36,6 @@
#define DRV_DESCRIPTION "Cisco VIC Ethernet NIC Driver"
#define DRV_VERSION "1.3.1.1-pp"
#define DRV_COPYRIGHT "Copyright 2008-2009 Cisco Systems, Inc"
-#define PFX DRV_NAME ": "
#define ENIC_LRO_MAX_DESC 8
#define ENIC_LRO_MAX_AGGR 64
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 6586b5c..8b3f300 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -17,6 +17,8 @@
*
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/string.h>
@@ -399,15 +401,15 @@ static void enic_log_q_error(struct enic *enic)
for (i = 0; i < enic->wq_count; i++) {
error_status = vnic_wq_error_status(&enic->wq[i]);
if (error_status)
- printk(KERN_ERR PFX "%s: WQ[%d] error_status %d\n",
- enic->netdev->name, i, error_status);
+ netdev_err(enic->netdev, "WQ[%d] error_status %d\n",
+ i, error_status);
}
for (i = 0; i < enic->rq_count; i++) {
error_status = vnic_rq_error_status(&enic->rq[i]);
if (error_status)
- printk(KERN_ERR PFX "%s: RQ[%d] error_status %d\n",
- enic->netdev->name, i, error_status);
+ netdev_err(enic->netdev, "RQ[%d] error_status %d\n",
+ i, error_status);
}
}
@@ -417,10 +419,10 @@ static void enic_link_check(struct enic *enic)
int carrier_ok = netif_carrier_ok(enic->netdev);
if (link_status && !carrier_ok) {
- printk(KERN_INFO PFX "%s: Link UP\n", enic->netdev->name);
+ netdev_info(enic->netdev, "Link UP\n");
netif_carrier_on(enic->netdev);
} else if (!link_status && carrier_ok) {
- printk(KERN_INFO PFX "%s: Link DOWN\n", enic->netdev->name);
+ netdev_info(enic->netdev, "Link DOWN\n");
netif_carrier_off(enic->netdev);
}
}
@@ -432,10 +434,10 @@ static void enic_mtu_check(struct enic *enic)
if (mtu && mtu != enic->port_mtu) {
enic->port_mtu = mtu;
if (mtu < enic->netdev->mtu)
- printk(KERN_WARNING PFX
- "%s: interface MTU (%d) set higher "
- "than switch port MTU (%d)\n",
- enic->netdev->name, enic->netdev->mtu, mtu);
+ netdev_warn(enic->netdev,
+ "interface MTU (%d) set higher "
+ "than switch port MTU (%d)\n",
+ enic->netdev->mtu, mtu);
}
}
@@ -444,8 +446,8 @@ static void enic_msglvl_check(struct enic *enic)
u32 msg_enable = vnic_dev_msg_lvl(enic->vdev);
if (msg_enable != enic->msg_enable) {
- printk(KERN_INFO PFX "%s: msg lvl changed from 0x%x to 0x%x\n",
- enic->netdev->name, enic->msg_enable, msg_enable);
+ netdev_info(enic->netdev, "msg lvl changed from 0x%x to 0x%x\n",
+ enic->msg_enable, msg_enable);
enic->msg_enable = msg_enable;
}
}
@@ -769,8 +771,7 @@ static netdev_tx_t enic_hard_start_xmit(struct sk_buff *skb,
skb_shinfo(skb)->nr_frags + ENIC_DESC_MAX_SPLITS) {
netif_stop_queue(netdev);
/* This is a hard error, log it */
- printk(KERN_ERR PFX "%s: BUG! Tx ring full when "
- "queue awake!\n", netdev->name);
+ netdev_err(netdev, "BUG! Tx ring full when queue awake!\n");
spin_unlock_irqrestore(&enic->wq_lock[0], flags);
return NETDEV_TX_BUSY;
}
@@ -1703,16 +1704,13 @@ static int enic_open(struct net_device *netdev)
err = enic_request_intr(enic);
if (err) {
- printk(KERN_ERR PFX "%s: Unable to request irq.\n",
- netdev->name);
+ netdev_err(netdev, "Unable to request irq\n");
return err;
}
err = enic_notify_set(enic);
if (err) {
- printk(KERN_ERR PFX
- "%s: Failed to alloc notify buffer, aborting.\n",
- netdev->name);
+ netdev_err(netdev, "Failed to alloc notify buffer, aborting\n");
goto err_out_free_intr;
}
@@ -1720,9 +1718,7 @@ static int enic_open(struct net_device *netdev)
vnic_rq_fill(&enic->rq[i], enic->rq_alloc_buf);
/* Need at least one buffer on ring to get going */
if (vnic_rq_desc_used(&enic->rq[i]) == 0) {
- printk(KERN_ERR PFX
- "%s: Unable to alloc receive buffers.\n",
- netdev->name);
+ netdev_err(netdev, "Unable to alloc receive buffers\n");
err = -ENOMEM;
goto err_out_notify_unset;
}
@@ -1824,10 +1820,9 @@ static int enic_change_mtu(struct net_device *netdev, int new_mtu)
netdev->mtu = new_mtu;
if (netdev->mtu > enic->port_mtu)
- printk(KERN_WARNING PFX
- "%s: interface MTU (%d) set higher "
- "than port MTU (%d)\n",
- netdev->name, netdev->mtu, enic->port_mtu);
+ netdev_warn(netdev,
+ "interface MTU (%d) set higher than port MTU (%d)\n",
+ netdev->mtu, enic->port_mtu);
if (running)
enic_open(netdev);
@@ -1900,8 +1895,8 @@ static int enic_dev_open(struct enic *enic)
err = enic_dev_wait(enic->vdev, vnic_dev_open,
vnic_dev_open_done, 0);
if (err)
- printk(KERN_ERR PFX
- "vNIC device open failed, err %d.\n", err);
+ netdev_err(enic->netdev, "vNIC device open failed, err %d\n",
+ err);
return err;
}
@@ -1913,8 +1908,8 @@ static int enic_dev_soft_reset(struct enic *enic)
err = enic_dev_wait(enic->vdev, vnic_dev_soft_reset,
vnic_dev_soft_reset_done, 0);
if (err)
- printk(KERN_ERR PFX
- "vNIC soft reset failed, err %d.\n", err);
+ netdev_err(enic->netdev, "vNIC soft reset failed, err %d\n",
+ err);
return err;
}
@@ -2122,8 +2117,7 @@ int enic_dev_init(struct enic *enic)
err = enic_get_vnic_config(enic);
if (err) {
- printk(KERN_ERR PFX
- "Get vNIC configuration failed, aborting.\n");
+ netdev_err(netdev, "Get vNIC configuration failed, aborting\n");
return err;
}
@@ -2138,9 +2132,9 @@ int enic_dev_init(struct enic *enic)
err = enic_set_intr_mode(enic);
if (err) {
- printk(KERN_ERR PFX
- "Failed to set intr mode based on resource "
- "counts and system capabilities, aborting.\n");
+ netdev_err(netdev,
+ "Failed to set intr mode based on resource "
+ "counts and system capabilities, aborting\n");
return err;
}
@@ -2149,8 +2143,7 @@ int enic_dev_init(struct enic *enic)
err = enic_alloc_vnic_resources(enic);
if (err) {
- printk(KERN_ERR PFX
- "Failed to alloc vNIC resources, aborting.\n");
+ netdev_err(netdev, "Failed to alloc vNIC resources, aborting\n");
goto err_out_free_vnic_resources;
}
@@ -2158,15 +2151,13 @@ int enic_dev_init(struct enic *enic)
err = enic_set_rq_alloc_buf(enic);
if (err) {
- printk(KERN_ERR PFX
- "Failed to set RQ buffer allocator, aborting.\n");
+ netdev_err(netdev, "Failed to set RQ buffer allocator, aborting\n");
goto err_out_free_vnic_resources;
}
err = enic_set_niccfg(enic);
if (err) {
- printk(KERN_ERR PFX
- "Failed to config nic, aborting.\n");
+ netdev_err(netdev, "Failed to config nic, aborting\n");
goto err_out_free_vnic_resources;
}
@@ -2212,7 +2203,7 @@ static int __devinit enic_probe(struct pci_dev *pdev,
netdev = alloc_etherdev(sizeof(struct enic));
if (!netdev) {
- printk(KERN_ERR PFX "Etherdev alloc failed, aborting.\n");
+ pr_err("Etherdev alloc failed, aborting\n");
return -ENOMEM;
}
@@ -2229,15 +2220,13 @@ static int __devinit enic_probe(struct pci_dev *pdev,
err = pci_enable_device(pdev);
if (err) {
- printk(KERN_ERR PFX
- "Cannot enable PCI device, aborting.\n");
+ netdev_err(netdev, "Cannot enable PCI device, aborting\n");
goto err_out_free_netdev;
}
err = pci_request_regions(pdev, DRV_NAME);
if (err) {
- printk(KERN_ERR PFX
- "Cannot request PCI regions, aborting.\n");
+ netdev_err(netdev, "Cannot request PCI regions, aborting\n");
goto err_out_disable_device;
}
@@ -2252,23 +2241,23 @@ static int __devinit enic_probe(struct pci_dev *pdev,
if (err) {
err = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
if (err) {
- printk(KERN_ERR PFX
- "No usable DMA configuration, aborting.\n");
+ netdev_err(netdev,
+ "No usable DMA configuration, aborting\n");
goto err_out_release_regions;
}
err = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(32));
if (err) {
- printk(KERN_ERR PFX
- "Unable to obtain 32-bit DMA "
- "for consistent allocations, aborting.\n");
+ netdev_err(netdev,
+ "Unable to obtain %u-bit DMA for consistent allocations, aborting\n",
+ 32);
goto err_out_release_regions;
}
} else {
err = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(40));
if (err) {
- printk(KERN_ERR PFX
- "Unable to obtain 40-bit DMA "
- "for consistent allocations, aborting.\n");
+ netdev_err(netdev,
+ "Unable to obtain %u-bit DMA for consistent allocations, aborting\n",
+ 40);
goto err_out_release_regions;
}
using_dac = 1;
@@ -2283,8 +2272,7 @@ static int __devinit enic_probe(struct pci_dev *pdev,
enic->bar[i].len = pci_resource_len(pdev, i);
enic->bar[i].vaddr = pci_iomap(pdev, i, enic->bar[i].len);
if (!enic->bar[i].vaddr) {
- printk(KERN_ERR PFX
- "Cannot memory-map BAR %d, aborting.\n", i);
+ netdev_err(netdev, "Cannot memory-map BAR %d, aborting\n", i);
err = -ENODEV;
goto err_out_iounmap;
}
@@ -2297,8 +2285,7 @@ static int __devinit enic_probe(struct pci_dev *pdev,
enic->vdev = vnic_dev_register(NULL, enic, pdev, enic->bar,
ARRAY_SIZE(enic->bar));
if (!enic->vdev) {
- printk(KERN_ERR PFX
- "vNIC registration failed, aborting.\n");
+ netdev_err(netdev, "vNIC registration failed, aborting\n");
err = -ENODEV;
goto err_out_iounmap;
}
@@ -2308,8 +2295,7 @@ static int __devinit enic_probe(struct pci_dev *pdev,
err = enic_dev_open(enic);
if (err) {
- printk(KERN_ERR PFX
- "vNIC dev open failed, aborting.\n");
+ netdev_err(netdev, "vNIC dev open failed, aborting\n");
goto err_out_vnic_unregister;
}
@@ -2326,16 +2312,14 @@ static int __devinit enic_probe(struct pci_dev *pdev,
if (!enic_is_dynamic(enic)) {
err = vnic_dev_init(enic->vdev, 0);
if (err) {
- printk(KERN_ERR PFX
- "vNIC dev init failed, aborting.\n");
+ netdev_err(netdev, "vNIC dev init failed, aborting\n");
goto err_out_dev_close;
}
}
err = enic_dev_init(enic);
if (err) {
- printk(KERN_ERR PFX
- "Device initialization failed, aborting.\n");
+ netdev_err(netdev, "Device initialization failed, aborting\n");
goto err_out_dev_close;
}
@@ -2361,8 +2345,7 @@ static int __devinit enic_probe(struct pci_dev *pdev,
err = enic_set_mac_addr(netdev, enic->mac_addr);
if (err) {
- printk(KERN_ERR PFX
- "Invalid MAC address, aborting.\n");
+ netdev_err(netdev, "Invalid MAC address, aborting\n");
goto err_out_dev_deinit;
}
@@ -2401,8 +2384,7 @@ static int __devinit enic_probe(struct pci_dev *pdev,
err = register_netdev(netdev);
if (err) {
- printk(KERN_ERR PFX
- "Cannot register net device, aborting.\n");
+ netdev_err(netdev, "Cannot register net device, aborting\n");
goto err_out_dev_deinit;
}
@@ -2456,7 +2438,7 @@ static struct pci_driver enic_driver = {
static int __init enic_init_module(void)
{
- printk(KERN_INFO PFX "%s, ver %s\n", DRV_DESCRIPTION, DRV_VERSION);
+ pr_info("%s, ver %s\n", DRV_DESCRIPTION, DRV_VERSION);
return pci_register_driver(&enic_driver);
}
diff --git a/drivers/net/enic/enic_res.c b/drivers/net/enic/enic_res.c
index 9b18840..b69a016 100644
--- a/drivers/net/enic/enic_res.c
+++ b/drivers/net/enic/enic_res.c
@@ -46,7 +46,7 @@ int enic_get_vnic_config(struct enic *enic)
err = vnic_dev_mac_addr(enic->vdev, enic->mac_addr);
if (err) {
- printk(KERN_ERR PFX "Error getting MAC addr, %d\n", err);
+ netdev_err(enic->netdev, "Error getting MAC addr, %d\n", err);
return err;
}
@@ -56,8 +56,8 @@ int enic_get_vnic_config(struct enic *enic)
offsetof(struct vnic_enet_config, m), \
sizeof(c->m), &c->m); \
if (err) { \
- printk(KERN_ERR PFX \
- "Error getting %s, %d\n", #m, err); \
+ netdev_err(enic->netdev, \
+ "Error getting %s, %d\n", #m, err); \
return err; \
} \
} while (0)
@@ -92,13 +92,13 @@ int enic_get_vnic_config(struct enic *enic)
INTR_COALESCE_HW_TO_USEC(VNIC_INTR_TIMER_MAX),
c->intr_timer_usec);
- printk(KERN_INFO PFX "vNIC MAC addr %pM wq/rq %d/%d\n",
- enic->mac_addr, c->wq_desc_count, c->rq_desc_count);
- printk(KERN_INFO PFX "vNIC mtu %d csum tx/rx %d/%d tso/lro %d/%d "
- "intr timer %d usec\n",
- c->mtu, ENIC_SETTING(enic, TXCSUM),
- ENIC_SETTING(enic, RXCSUM), ENIC_SETTING(enic, TSO),
- ENIC_SETTING(enic, LRO), c->intr_timer_usec);
+ netdev_info(enic->netdev, "vNIC MAC addr %pM wq/rq %d/%d\n",
+ enic->mac_addr, c->wq_desc_count, c->rq_desc_count);
+ netdev_info(enic->netdev, "vNIC mtu %d csum tx/rx %d/%d tso/lro %d/%d "
+ "intr timer %d usec\n",
+ c->mtu, ENIC_SETTING(enic, TXCSUM),
+ ENIC_SETTING(enic, RXCSUM), ENIC_SETTING(enic, TSO),
+ ENIC_SETTING(enic, LRO), c->intr_timer_usec);
return 0;
}
@@ -121,7 +121,7 @@ void enic_add_vlan(struct enic *enic, u16 vlanid)
err = vnic_dev_cmd(enic->vdev, CMD_VLAN_ADD, &a0, &a1, wait);
if (err)
- printk(KERN_ERR PFX "Can't add vlan id, %d\n", err);
+ netdev_err(enic->netdev, "Can't add vlan id, %d\n", err);
}
void enic_del_vlan(struct enic *enic, u16 vlanid)
@@ -132,7 +132,7 @@ void enic_del_vlan(struct enic *enic, u16 vlanid)
err = vnic_dev_cmd(enic->vdev, CMD_VLAN_DEL, &a0, &a1, wait);
if (err)
- printk(KERN_ERR PFX "Can't delete vlan id, %d\n", err);
+ netdev_err(enic->netdev, "Can't delete vlan id, %d\n", err);
}
int enic_set_nic_cfg(struct enic *enic, u8 rss_default_cpu, u8 rss_hash_type,
@@ -198,10 +198,10 @@ void enic_get_res_counts(struct enic *enic)
vnic_dev_get_res_count(enic->vdev, RES_TYPE_INTR_CTRL),
ENIC_INTR_MAX);
- printk(KERN_INFO PFX "vNIC resources avail: "
- "wq %d rq %d cq %d intr %d\n",
- enic->wq_count, enic->rq_count,
- enic->cq_count, enic->intr_count);
+ netdev_info(enic->netdev, "vNIC resources avail: "
+ "wq %d rq %d cq %d intr %d\n",
+ enic->wq_count, enic->rq_count,
+ enic->cq_count, enic->intr_count);
}
void enic_init_vnic_resources(struct enic *enic)
@@ -319,15 +319,14 @@ int enic_alloc_vnic_resources(struct enic *enic)
intr_mode = vnic_dev_get_intr_mode(enic->vdev);
- printk(KERN_INFO PFX "vNIC resources used: "
- "wq %d rq %d cq %d intr %d intr mode %s\n",
- enic->wq_count, enic->rq_count,
- enic->cq_count, enic->intr_count,
- intr_mode == VNIC_DEV_INTR_MODE_INTX ? "legacy PCI INTx" :
- intr_mode == VNIC_DEV_INTR_MODE_MSI ? "MSI" :
- intr_mode == VNIC_DEV_INTR_MODE_MSIX ? "MSI-X" :
- "unknown"
- );
+ netdev_info(enic->netdev, "vNIC resources used: "
+ "wq %d rq %d cq %d intr %d intr mode %s\n",
+ enic->wq_count, enic->rq_count,
+ enic->cq_count, enic->intr_count,
+ intr_mode == VNIC_DEV_INTR_MODE_INTX ? "legacy PCI INTx" :
+ intr_mode == VNIC_DEV_INTR_MODE_MSI ? "MSI" :
+ intr_mode == VNIC_DEV_INTR_MODE_MSIX ? "MSI-X" :
+ "unknown");
/* Allocate queue resources
*/
@@ -373,7 +372,7 @@ int enic_alloc_vnic_resources(struct enic *enic)
enic->legacy_pba = vnic_dev_get_res(enic->vdev,
RES_TYPE_INTR_PBA_LEGACY, 0);
if (!enic->legacy_pba && intr_mode == VNIC_DEV_INTR_MODE_INTX) {
- printk(KERN_ERR PFX "Failed to hook legacy pba resource\n");
+ netdev_err(enic->netdev, "Failed to hook legacy pba resource\n");
err = -ENODEV;
goto err_out_cleanup;
}
diff --git a/drivers/net/enic/vnic_cq.c b/drivers/net/enic/vnic_cq.c
index 020ae6c..326ea40 100644
--- a/drivers/net/enic/vnic_cq.c
+++ b/drivers/net/enic/vnic_cq.c
@@ -42,7 +42,7 @@ int vnic_cq_alloc(struct vnic_dev *vdev, struct vnic_cq *cq, unsigned int index,
cq->ctrl = vnic_dev_get_res(vdev, RES_TYPE_CQ, index);
if (!cq->ctrl) {
- printk(KERN_ERR "Failed to hook CQ[%d] resource\n", index);
+ pr_err("Failed to hook CQ[%d] resource\n", index);
return -EINVAL;
}
diff --git a/drivers/net/enic/vnic_dev.c b/drivers/net/enic/vnic_dev.c
index 2b3e16d..6a7fb71 100644
--- a/drivers/net/enic/vnic_dev.c
+++ b/drivers/net/enic/vnic_dev.c
@@ -17,6 +17,8 @@
*
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/types.h>
@@ -78,22 +80,22 @@ static int vnic_dev_discover_res(struct vnic_dev *vdev,
return -EINVAL;
if (bar->len < VNIC_MAX_RES_HDR_SIZE) {
- printk(KERN_ERR "vNIC BAR0 res hdr length error\n");
+ pr_err("vNIC BAR0 res hdr length error\n");
return -EINVAL;
}
rh = bar->vaddr;
if (!rh) {
- printk(KERN_ERR "vNIC BAR0 res hdr not mem-mapped\n");
+ pr_err("vNIC BAR0 res hdr not mem-mapped\n");
return -EINVAL;
}
if (ioread32(&rh->magic) != VNIC_RES_MAGIC ||
ioread32(&rh->version) != VNIC_RES_VERSION) {
- printk(KERN_ERR "vNIC BAR0 res magic/version error "
- "exp (%lx/%lx) curr (%x/%x)\n",
- VNIC_RES_MAGIC, VNIC_RES_VERSION,
- ioread32(&rh->magic), ioread32(&rh->version));
+ pr_err("vNIC BAR0 res magic/version error "
+ "exp (%lx/%lx) curr (%x/%x)\n",
+ VNIC_RES_MAGIC, VNIC_RES_VERSION,
+ ioread32(&rh->magic), ioread32(&rh->version));
return -EINVAL;
}
@@ -122,7 +124,7 @@ static int vnic_dev_discover_res(struct vnic_dev *vdev,
/* each count is stride bytes long */
len = count * VNIC_RES_STRIDE;
if (len + bar_offset > bar[bar_num].len) {
- printk(KERN_ERR "vNIC BAR0 resource %d "
+ pr_err("vNIC BAR0 resource %d "
"out-of-bounds, offset 0x%x + "
"size 0x%x > bar len 0x%lx\n",
type, bar_offset,
@@ -229,8 +231,7 @@ int vnic_dev_alloc_desc_ring(struct vnic_dev *vdev, struct vnic_dev_ring *ring,
&ring->base_addr_unaligned);
if (!ring->descs_unaligned) {
- printk(KERN_ERR
- "Failed to allocate ring (size=%d), aborting\n",
+ pr_err("Failed to allocate ring (size=%d), aborting\n",
(int)ring->size);
return -ENOMEM;
}
@@ -268,7 +269,7 @@ int vnic_dev_cmd(struct vnic_dev *vdev, enum vnic_devcmd_cmd cmd,
status = ioread32(&devcmd->status);
if (status & STAT_BUSY) {
- printk(KERN_ERR "Busy devcmd %d\n", _CMD_N(cmd));
+ pr_err("Busy devcmd %d\n", _CMD_N(cmd));
return -EBUSY;
}
@@ -294,7 +295,7 @@ int vnic_dev_cmd(struct vnic_dev *vdev, enum vnic_devcmd_cmd cmd,
err = (int)readq(&devcmd->args[0]);
if (err != ERR_ECMDUNKNOWN ||
cmd != CMD_CAPABILITY)
- printk(KERN_ERR "Error %d devcmd %d\n",
+ pr_err("Error %d devcmd %d\n",
err, _CMD_N(cmd));
return err;
}
@@ -309,7 +310,7 @@ int vnic_dev_cmd(struct vnic_dev *vdev, enum vnic_devcmd_cmd cmd,
}
}
- printk(KERN_ERR "Timedout devcmd %d\n", _CMD_N(cmd));
+ pr_err("Timedout devcmd %d\n", _CMD_N(cmd));
return -ETIMEDOUT;
}
@@ -527,7 +528,7 @@ void vnic_dev_packet_filter(struct vnic_dev *vdev, int directed, int multicast,
err = vnic_dev_cmd(vdev, CMD_PACKET_FILTER, &a0, &a1, wait);
if (err)
- printk(KERN_ERR "Can't set packet filter\n");
+ pr_err("Can't set packet filter\n");
}
int vnic_dev_add_addr(struct vnic_dev *vdev, u8 *addr)
@@ -542,7 +543,7 @@ int vnic_dev_add_addr(struct vnic_dev *vdev, u8 *addr)
err = vnic_dev_cmd(vdev, CMD_ADDR_ADD, &a0, &a1, wait);
if (err)
- printk(KERN_ERR "Can't add addr [%pM], %d\n", addr, err);
+ pr_err("Can't add addr [%pM], %d\n", addr, err);
return err;
}
@@ -559,7 +560,7 @@ int vnic_dev_del_addr(struct vnic_dev *vdev, u8 *addr)
err = vnic_dev_cmd(vdev, CMD_ADDR_DEL, &a0, &a1, wait);
if (err)
- printk(KERN_ERR "Can't del addr [%pM], %d\n", addr, err);
+ pr_err("Can't del addr [%pM], %d\n", addr, err);
return err;
}
@@ -572,8 +573,7 @@ int vnic_dev_raise_intr(struct vnic_dev *vdev, u16 intr)
err = vnic_dev_cmd(vdev, CMD_IAR, &a0, &a1, wait);
if (err)
- printk(KERN_ERR "Failed to raise INTR[%d], err %d\n",
- intr, err);
+ pr_err("Failed to raise INTR[%d], err %d\n", intr, err);
return err;
}
@@ -604,8 +604,7 @@ int vnic_dev_notify_set(struct vnic_dev *vdev, u16 intr)
dma_addr_t notify_pa;
if (vdev->notify || vdev->notify_pa) {
- printk(KERN_ERR "notify block %p still allocated",
- vdev->notify);
+ pr_err("notify block %p still allocated", vdev->notify);
return -EINVAL;
}
diff --git a/drivers/net/enic/vnic_intr.c b/drivers/net/enic/vnic_intr.c
index 3934309..617e744 100644
--- a/drivers/net/enic/vnic_intr.c
+++ b/drivers/net/enic/vnic_intr.c
@@ -17,6 +17,8 @@
*
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/types.h>
@@ -39,8 +41,7 @@ int vnic_intr_alloc(struct vnic_dev *vdev, struct vnic_intr *intr,
intr->ctrl = vnic_dev_get_res(vdev, RES_TYPE_INTR_CTRL, index);
if (!intr->ctrl) {
- printk(KERN_ERR "Failed to hook INTR[%d].ctrl resource\n",
- index);
+ pr_err("Failed to hook INTR[%d].ctrl resource\n", index);
return -EINVAL;
}
diff --git a/drivers/net/enic/vnic_rq.c b/drivers/net/enic/vnic_rq.c
index cc580cf..0e456a2 100644
--- a/drivers/net/enic/vnic_rq.c
+++ b/drivers/net/enic/vnic_rq.c
@@ -17,6 +17,8 @@
*
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/types.h>
@@ -39,7 +41,7 @@ static int vnic_rq_alloc_bufs(struct vnic_rq *rq)
for (i = 0; i < blks; i++) {
rq->bufs[i] = kzalloc(VNIC_RQ_BUF_BLK_SZ, GFP_ATOMIC);
if (!rq->bufs[i]) {
- printk(KERN_ERR "Failed to alloc rq_bufs\n");
+ pr_err("Failed to alloc rq_bufs\n");
return -ENOMEM;
}
}
@@ -94,7 +96,7 @@ int vnic_rq_alloc(struct vnic_dev *vdev, struct vnic_rq *rq, unsigned int index,
rq->ctrl = vnic_dev_get_res(vdev, RES_TYPE_RQ, index);
if (!rq->ctrl) {
- printk(KERN_ERR "Failed to hook RQ[%d] resource\n", index);
+ pr_err("Failed to hook RQ[%d] resource\n", index);
return -EINVAL;
}
@@ -174,7 +176,7 @@ int vnic_rq_disable(struct vnic_rq *rq)
udelay(10);
}
- printk(KERN_ERR "Failed to disable RQ[%d]\n", rq->index);
+ pr_err("Failed to disable RQ[%d]\n", rq->index);
return -ETIMEDOUT;
}
diff --git a/drivers/net/enic/vnic_wq.c b/drivers/net/enic/vnic_wq.c
index 1378afb..abf4c27 100644
--- a/drivers/net/enic/vnic_wq.c
+++ b/drivers/net/enic/vnic_wq.c
@@ -17,6 +17,8 @@
*
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/types.h>
@@ -39,7 +41,7 @@ static int vnic_wq_alloc_bufs(struct vnic_wq *wq)
for (i = 0; i < blks; i++) {
wq->bufs[i] = kzalloc(VNIC_WQ_BUF_BLK_SZ, GFP_ATOMIC);
if (!wq->bufs[i]) {
- printk(KERN_ERR "Failed to alloc wq_bufs\n");
+ pr_err("Failed to alloc wq_bufs\n");
return -ENOMEM;
}
}
@@ -94,7 +96,7 @@ int vnic_wq_alloc(struct vnic_dev *vdev, struct vnic_wq *wq, unsigned int index,
wq->ctrl = vnic_dev_get_res(vdev, RES_TYPE_WQ, index);
if (!wq->ctrl) {
- printk(KERN_ERR "Failed to hook WQ[%d] resource\n", index);
+ pr_err("Failed to hook WQ[%d] resource\n", index);
return -EINVAL;
}
@@ -167,7 +169,7 @@ int vnic_wq_disable(struct vnic_wq *wq)
udelay(10);
}
- printk(KERN_ERR "Failed to disable WQ[%d]\n", wq->index);
+ pr_err("Failed to disable WQ[%d]\n", wq->index);
return -ETIMEDOUT;
}
^ permalink raw reply related
* Re: [PATCH] ppp_generic: fix multilink fragment sizes
From: David Miller @ 2010-06-02 15:31 UTC (permalink / raw)
To: gabriele.paoloni; +Cc: ben, netdev, linux-kernel, alan, linux-ppp, paulus
In-Reply-To: <DF7BB929B28FCF479E888E3D9F8D9E88D3E16B5A@irsmsx502.ger.corp.intel.com>
From: "Paoloni, Gabriele" <gabriele.paoloni@intel.com>
Date: Wed, 2 Jun 2010 16:17:59 +0100
> The proposed patch looks wrong to me.
Can you please reply to postings properly? Use the reply function
of your mail client and do not "top post."
Because of the way you just simply inlined the entirety of Ben's
patch posting, it ends up looking like a new patch being posted
on patchwork and this makes more work and analysis for me.
Thanks.
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Eric Dumazet @ 2010-06-02 15:32 UTC (permalink / raw)
To: Christoph Lameter; +Cc: netdev, Stephen Hemminger, David Miller
In-Reply-To: <alpine.DEB.2.00.1006021025200.30182@router.home>
Le mercredi 02 juin 2010 à 10:27 -0500, Christoph Lameter a écrit :
> Yes but they are not increment any counter. If packets are dropped because
> of the rp_filter setting interfering f.e. then the packets vanish without
> any accounting.
>
But packets are vanishing either way.
> LINUX_MIB_INROUTEERRORS? Does it mean I can create a series of new
> counters that allow us to diagnose and distinguish all the different
> causes of packet loss? We would love to have that.
>
For an example, you could take a look at commit 907cdda5205b
(tcp: Add SNMP counter for DEFER_ACCEPT)
Its pretty straigthforward, and wont conflict with monitoring apps.
^ permalink raw reply
* Re: [PATCH 2/2] mac8390: raise error logging priority
From: Finn Thain @ 2010-06-02 15:36 UTC (permalink / raw)
To: David Miller; +Cc: geert, joe, p_gortmaker, netdev, linux-kernel, linux-m68k
In-Reply-To: <20100602.070647.106817718.davem@davemloft.net>
On Wed, 2 Jun 2010, David Miller wrote:
>
> Applied, thank you.
>
You're welcome.
And I ought to add, thanks, Joe, for your patches.
It is much harder than I had realised to do them right (or for that
matter, well enough).
Finn
^ permalink raw reply
* Re: sysfs class/net/ problem
From: Greg KH @ 2010-06-02 15:46 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, Eric W. Biederman
In-Reply-To: <1275484611.3915.11.camel@jlt3.sipsolutions.net>
On Wed, Jun 02, 2010 at 03:16:51PM +0200, Johannes Berg wrote:
> Hi,
>
> I didn't find anything related in the archives, if I missed it I'd
> appreciate a pointer. I'm currently experiencing the following:
>
> # ip link
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
> link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
> # ls -l /sys/class/net/
> total 0
> lrwxrwxrwx 1 root root 0 Jun 2 13:12 eth0 -> ../../devices/pci0000:00/0000:00:03.0/net/eth0
> lrwxrwxrwx 1 root root 0 Jun 2 13:12 lo -> ../../devices/virtual/net/lo
> # insmod cfg80211.ko ; insmod mac80211.ko ; insmod mac80211_hwsim.ko radios=3
> # ip link
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
> link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
> 5: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
> link/ether 02:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> 6: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
> link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
> 7: wlan2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
> link/ether 02:00:00:00:02:00 brd ff:ff:ff:ff:ff:ff
> 8: hwsim0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
> link/ieee802.11/radiotap 12:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> # ls -l /sys/class/net/
> total 0
> lrwxrwxrwx 1 root root 0 Jun 2 13:12 eth0 -> ../../devices/pci0000:00/0000:00:03.0/net/eth0
> lrwxrwxrwx 1 root root 0 Jun 2 13:14 hwsim0 -> ../../devices/virtual/net/hwsim0
> lrwxrwxrwx 1 root root 0 Jun 2 13:12 lo -> ../../devices/virtual/net/lo
> lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan0 -> ../../devices/virtual/mac80211_hwsim/hwsim0/wlan0
> lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan1 -> ../../devices/virtual/mac80211_hwsim/hwsim1/wlan1
> lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan2 -> ../../devices/virtual/mac80211_hwsim/hwsim2/wlan2
> # rmmod mac80211_hwsim mac80211 cfg80211
> # ip link
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
> link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
> # ls -l /sys/class/net/
> total 0
> lrwxrwxrwx 1 root root 0 Jun 2 13:12 eth0 -> ../../devices/pci0000:00/0000:00:03.0/net/eth0
> lrwxrwxrwx 1 root root 0 Jun 2 13:12 lo -> ../../devices/virtual/net/lo
> lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan0 -> ../../devices/virtual/mac80211_hwsim/hwsim0/wlan0
> lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan1 -> ../../devices/virtual/mac80211_hwsim/hwsim1/wlan1
> lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan2 -> ../../devices/virtual/mac80211_hwsim/hwsim2/wlan2
Ah, so the network devices aren't getting removed?
Do you have network namespaces enabled in your kernel or disabled?
And this is 2.6.35-rc1, right?
Eric, any ideas?
thanks,
greg k-h
^ permalink raw reply
* Re: sysfs class/net/ problem
From: Johannes Berg @ 2010-06-02 15:48 UTC (permalink / raw)
To: Greg KH; +Cc: netdev, Eric W. Biederman
In-Reply-To: <20100602154608.GB12361@kroah.com>
On Wed, 2010-06-02 at 08:46 -0700, Greg KH wrote:
> > # rmmod mac80211_hwsim mac80211 cfg80211
> > # ip link
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
> > link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
> > # ls -l /sys/class/net/
> > total 0
> > lrwxrwxrwx 1 root root 0 Jun 2 13:12 eth0 -> ../../devices/pci0000:00/0000:00:03.0/net/eth0
> > lrwxrwxrwx 1 root root 0 Jun 2 13:12 lo -> ../../devices/virtual/net/lo
> > lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan0 -> ../../devices/virtual/mac80211_hwsim/hwsim0/wlan0
> > lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan1 -> ../../devices/virtual/mac80211_hwsim/hwsim1/wlan1
> > lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan2 -> ../../devices/virtual/mac80211_hwsim/hwsim2/wlan2
>
> Ah, so the network devices aren't getting removed?
Well the netdevs are gone, just the links aren't going away. the
mac80211_hwsim directory is gone too.
> Do you have network namespaces enabled in your kernel or disabled?
enabled
> And this is 2.6.35-rc1, right?
yes.
Come to think of it, maybe somehow it ends up removing
mac80211_hwsim/hwsim0 before wlan0, and thus the link stays around? I
guess I could make it print messages about that somehow?
johannes
^ permalink raw reply
* Re: [PATCH] ppp_generic: fix multilink fragment sizes
From: Ben McKeegan @ 2010-06-02 15:55 UTC (permalink / raw)
To: Paoloni, Gabriele
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, alan@lxorguk.ukuu.org.uk,
linux-ppp@vger.kernel.org, paulus@samba.org
In-Reply-To: <DF7BB929B28FCF479E888E3D9F8D9E88D3E16B5A@irsmsx502.ger.corp.intel.com>
Paoloni, Gabriele wrote:
> The proposed patch looks wrong to me.
>
> nbigger is already doing the job; I didn't use DIV_ROUND_UP because in general we don't have always to roundup, otherwise we would exceed the total bandwidth.
I was basing this on the original code prior to your patch, which used
DIV_ROUND_UP to get the fragment size. Looking more closely I see your
point, the original code was starting with the larger fragment size and
decrementing rather than starting with the smaller size and incrementing
as your code does, so that makes sense.
>
> flen = len;
> if (nfree > 0) {
> if (pch->speed == 0) {
> - flen = totlen/nfree;
> + if (nfree > 1)
> + flen = DIV_ROUND_UP(len, nfree);
> if (nbigger > 0) {
> flen++;
> nbigger--;
The important change here is the use of 'len' instead of 'totlen'.
'nfree' and 'len' should decrease roughly proportionally with each
iteration of the loop whereas 'totlen' remains unchanged. Thus
(totlen/nfree) gets bigger on each iteration whereas len/nfree should
give roughly the same. However, without rounding up here I'm not sure
the logic is right either, since the side effect of nbigger is to make
len decrease faster so it is not quite proportional to the decrease in
nfree. Is there a risk of ending up on the nfree == 1 iteration with
flen == len - 1 and thus generating a superfluous extra 1 byte long
fragment? This would be a far worse situation than a slight imbalance
in the size of the fragments.
Perhaps the solution is to go back to a precalculated fragment size for
the pch->speed == 0 case as per original code?
Regards,
Ben.
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-05-28
From: reinette chatre @ 2010-06-02 16:01 UTC (permalink / raw)
To: sedat.dilek@gmail.com
Cc: John W. Linville, davem@davemloft.net,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Zheng, Jiajia, Kolekar, Abhijeet,
Berg, Johannes
In-Reply-To: <AANLkTimo_CpVC0B99GMJtIllAye5Yqa5yiIAiFBY-pIN@mail.gmail.com>
On Wed, 2010-06-02 at 01:42 -0700, Sedat Dilek wrote:
> What do you mean by "upstream"?
> upstream for me is Linus-tree (linux-2.6 GIT master).
> Patches against iwlwifi-2.6 GIT trees are not very helpful in my case.
Since the problem exists in 2.6.35-rc1 linux-2.6 is indeed the target
for this fix.
Reinette
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Christoph Lameter @ 2010-06-02 16:12 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Stephen Hemminger, David Miller
In-Reply-To: <1275492754.2725.192.camel@edumazet-laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1455 bytes --]
On Wed, 2 Jun 2010, Eric Dumazet wrote:
> Le mercredi 02 juin 2010 à 10:27 -0500, Christoph Lameter a écrit :
>
> > Yes but they are not increment any counter. If packets are dropped because
> > of the rp_filter setting interfering f.e. then the packets vanish without
> > any accounting.
> >
>
> But packets are vanishing either way.
Its important to know why drops occur (any drops for that matter, drops
mean retransmit which means latency). The symptom here was that
multicast traffic on secondary interfaces was not being forwarded to the application.
The rp_filter just dropped them and there was no way to easily track down
the issue for the people experiencing the problem.
In 2.6.31 the rp_filter was fixed to work properly with multicast and now
it considers multicast traffic to secondary interfaces to have the wrong
reverse path even though the multicast subscription occurred on the
secondary interface. So it drops multicast traffic. The rp_filter has to
be switched off when using multiple NICs for multicast load balancing.
> > LINUX_MIB_INROUTEERRORS? Does it mean I can create a series of new
> > counters that allow us to diagnose and distinguish all the different
> > causes of packet loss? We would love to have that.
> >
>
> For an example, you could take a look at commit 907cdda5205b
> (tcp: Add SNMP counter for DEFER_ACCEPT)
Well these are all TCP counters. I would add IP and UDP counters?
^ permalink raw reply
* Re: sysfs class/net/ problem
From: Eric W. Biederman @ 2010-06-02 16:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: Greg KH, netdev
In-Reply-To: <1275493693.3915.12.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Wed, 2010-06-02 at 08:46 -0700, Greg KH wrote:
>
>> > # rmmod mac80211_hwsim mac80211 cfg80211
>> > # ip link
>> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
>> > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
>> > link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
>> > # ls -l /sys/class/net/
>> > total 0
>> > lrwxrwxrwx 1 root root 0 Jun 2 13:12 eth0 -> ../../devices/pci0000:00/0000:00:03.0/net/eth0
>> > lrwxrwxrwx 1 root root 0 Jun 2 13:12 lo -> ../../devices/virtual/net/lo
>> > lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan0 -> ../../devices/virtual/mac80211_hwsim/hwsim0/wlan0
>> > lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan1 -> ../../devices/virtual/mac80211_hwsim/hwsim1/wlan1
>> > lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan2 -> ../../devices/virtual/mac80211_hwsim/hwsim2/wlan2
>>
>> Ah, so the network devices aren't getting removed?
>
> Well the netdevs are gone, just the links aren't going away. the
> mac80211_hwsim directory is gone too.
>
>> Do you have network namespaces enabled in your kernel or disabled?
>
> enabled
>
>> And this is 2.6.35-rc1, right?
>
> yes.
>
> Come to think of it, maybe somehow it ends up removing
> mac80211_hwsim/hwsim0 before wlan0, and thus the link stays around? I
> guess I could make it print messages about that somehow?
The wireless drivers are a little different, and come to think of it
network namespace support has been added to the wireless drivers since
last I looked closely. Do you know what creates/deletes these links?
Is it the normal register_netdevice -> device_add path?
I definitely changed the symlink code a little making things network namespace
aware so it is reasonable to assume that something in my changes affected the
wireless drivers.
I took a quick look and with my patches against 2.6.33 I'm not seeing this.
I take a closer look at 2.6.35-rc1 and see if I can figure out what is
going on. It would definitely be wrong if hwsim0 is removed before
wlan0. Still on my todo it seems is to fix the lifetime issues of all
of the callers, grr.
Eric
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: David Miller @ 2010-06-02 16:19 UTC (permalink / raw)
To: cl; +Cc: eric.dumazet, netdev, shemminger
In-Reply-To: <alpine.DEB.2.00.1006021103410.30182@router.home>
From: Christoph Lameter <cl@linux-foundation.org>
Date: Wed, 2 Jun 2010 11:12:14 -0500 (CDT)
> Its important to know why drops occur (any drops for that matter, drops
> mean retransmit which means latency).
We know, that's why there is a networking tracepoint that allows you
to see where all drops occur. :-)
^ permalink raw reply
* Re: sysfs class/net/ problem
From: Johannes Berg @ 2010-06-02 16:21 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Greg KH, netdev
In-Reply-To: <m1ljaxxvcj.fsf@fess.ebiederm.org>
On Wed, 2010-06-02 at 09:17 -0700, Eric W. Biederman wrote:
> >> Ah, so the network devices aren't getting removed?
> >
> > Well the netdevs are gone, just the links aren't going away. the
> > mac80211_hwsim directory is gone too.
> >
> >> Do you have network namespaces enabled in your kernel or disabled?
> >
> > enabled
> >
> >> And this is 2.6.35-rc1, right?
> >
> > yes.
> >
> > Come to think of it, maybe somehow it ends up removing
> > mac80211_hwsim/hwsim0 before wlan0, and thus the link stays around? I
> > guess I could make it print messages about that somehow?
>
> The wireless drivers are a little different, and come to think of it
> network namespace support has been added to the wireless drivers since
> last I looked closely.
Yeah, I now need to go add tagged sysfs support to it too.
> Do you know what creates/deletes these links?
> Is it the normal register_netdevice -> device_add path?
Yes, they aren't done specially.
> I definitely changed the symlink code a little making things network namespace
> aware so it is reasonable to assume that something in my changes affected the
> wireless drivers.
> I took a quick look and with my patches against 2.6.33 I'm not seeing this.
Hmm. I'm also not seeing it with veth, it would seem that ought to be
similar?
> I take a closer look at 2.6.35-rc1 and see if I can figure out what is
> going on. It would definitely be wrong if hwsim0 is removed before
> wlan0.
I don't know if that's happening .. just guessing that it might cause
such a problem, and maybe some things are deferred somehow? Since netdev
destruction can be deferred, but the wifi sysfs destruction isn't. But
then that link there should cause the refcount to not go down until the
link goes away>?
johannes
^ permalink raw reply
* RE: [PATCH net-next-2.6] net: replace hooks in __netif_receive_skb V5
From: Fischer, Anna @ 2010-06-02 16:20 UTC (permalink / raw)
To: Jiri Pirko, netdev@vger.kernel.org
Cc: davem@davemloft.net, kaber@trash.net, eric.dumazet@gmail.com,
shemminger@vyatta.com
In-Reply-To: <20100602075207.GD2603@psychotron.redhat.com>
> Subject: [PATCH net-next-2.6] net: replace hooks in __netif_receive_skb
> V5
>
> What this patch does is it removes two receive frame hooks (for bridge
> and for
> macvlan) from __netif_receive_skb. These are replaced them with a single
> hook for both. It only supports one hook per device because it makes no
> sense to do bridging and macvlan on the same device.
>
> Then a network driver (of virtual netdev like macvlan or bridge) can
> register
> an rx_handler for needed net device.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
I would like to see this being accepted. As mentioned before I would love to be able to support multiple receive frame hooks per device, but I think this is a good start.
I think especially with virtualization coming into Linux and new network virtualization approaches being developed it would be nice to have a more generic function for packet receive handlers to hook into the network stack more cleanly. Current approaches rely on 'misusing' the bridging hook into the kernel, because the packet 'sniffing' hooks (via dev_pack_add()) do not give enough control over packet processing.
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Christoph Lameter @ 2010-06-02 16:27 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev, shemminger
In-Reply-To: <20100602.091909.113727983.davem@davemloft.net>
On Wed, 2 Jun 2010, David Miller wrote:
> From: Christoph Lameter <cl@linux-foundation.org>
> Date: Wed, 2 Jun 2010 11:12:14 -0500 (CDT)
>
> > Its important to know why drops occur (any drops for that matter, drops
> > mean retransmit which means latency).
>
> We know, that's why there is a networking tracepoint that allows you
> to see where all drops occur. :-)
Where can I find out more about the network tracepoint?
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Eric Dumazet @ 2010-06-02 16:28 UTC (permalink / raw)
To: Christoph Lameter; +Cc: netdev, Stephen Hemminger, David Miller
In-Reply-To: <alpine.DEB.2.00.1006021103410.30182@router.home>
Le mercredi 02 juin 2010 à 11:12 -0500, Christoph Lameter a écrit :
> On Wed, 2 Jun 2010, Eric Dumazet wrote:
>
> > Le mercredi 02 juin 2010 à 10:27 -0500, Christoph Lameter a écrit :
> >
> > > Yes but they are not increment any counter. If packets are dropped because
> > > of the rp_filter setting interfering f.e. then the packets vanish without
> > > any accounting.
> > >
> >
> > But packets are vanishing either way.
>
> Its important to know why drops occur (any drops for that matter, drops
> mean retransmit which means latency). The symptom here was that
> multicast traffic on secondary interfaces was not being forwarded to the application.
> The rp_filter just dropped them and there was no way to easily track down
> the issue for the people experiencing the problem.
>
I just dont follow you.
Your patch has nothing to do with dropped packets because of rp_filter.
You inserted a counter increment in a path that is not taken at all by
packet delivery.
Maybe I missed something really obvious with your patch ?
It should only matters for the admin doing following command :
ip route get 1.2.3.4 from 192.168.0.1 iif eth0
That is a probe, not a 'packet delivery', this is why I said
incrementing an official MIB counter was probably wrong.
> In 2.6.31 the rp_filter was fixed to work properly with multicast and now
> it considers multicast traffic to secondary interfaces to have the wrong
> reverse path even though the multicast subscription occurred on the
> secondary interface. So it drops multicast traffic. The rp_filter has to
> be switched off when using multiple NICs for multicast load balancing.
>
Have you considered CONFIG_NET_DROP_MONITOR ?
This one catches all possible cases, a developper doesnt have to patch
his kernel to add SNMP counters everywhere...
config NET_DROP_MONITOR
boolean "Network packet drop alerting service"
depends on INET && EXPERIMENTAL && TRACEPOINTS
---help---
This feature provides an alerting service to userspace in the
event that packets are discarded in the network stack. Alerts
are broadcast via netlink socket to any listening user space
process. If you don't need network drop alerts, or if you are ok
just checking the various proc files and other utilities for
drop statistics, say N here.
> > > LINUX_MIB_INROUTEERRORS? Does it mean I can create a series of new
> > > counters that allow us to diagnose and distinguish all the different
> > > causes of packet loss? We would love to have that.
> > >
> >
> > For an example, you could take a look at commit 907cdda5205b
> > (tcp: Add SNMP counter for DEFER_ACCEPT)
>
> Well these are all TCP counters. I would add IP and UDP counters?
Why not ?
But as David said, it should be motivated by real use case ;)
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Eric Dumazet @ 2010-06-02 16:33 UTC (permalink / raw)
To: Christoph Lameter; +Cc: David Miller, netdev, shemminger
In-Reply-To: <alpine.DEB.2.00.1006021126500.30182@router.home>
Le mercredi 02 juin 2010 à 11:27 -0500, Christoph Lameter a écrit :
> On Wed, 2 Jun 2010, David Miller wrote:
>
> > From: Christoph Lameter <cl@linux-foundation.org>
> > Date: Wed, 2 Jun 2010 11:12:14 -0500 (CDT)
> >
> > > Its important to know why drops occur (any drops for that matter, drops
> > > mean retransmit which means latency).
> >
> > We know, that's why there is a networking tracepoint that allows you
> > to see where all drops occur. :-)
>
> Where can I find out more about the network tracepoint?
>
take a look at
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/html/SystemTap_Beginners_Guide/useful-systemtap-scripts.html#dropwatch
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Christoph Lameter @ 2010-06-02 16:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Stephen Hemminger, David Miller
In-Reply-To: <1275496088.2725.202.camel@edumazet-laptop>
On Wed, 2 Jun 2010, Eric Dumazet wrote:
> Your patch has nothing to do with dropped packets because of rp_filter.
>
> You inserted a counter increment in a path that is not taken at all by
> packet delivery.
>
> Maybe I missed something really obvious with your patch ?
rp_filter rejects a route and packets are dropped then.
> Have you considered CONFIG_NET_DROP_MONITOR ?
> This one catches all possible cases, a developper doesnt have to patch
> his kernel to add SNMP counters everywhere...
Just looking at it. Great. A hook into skb_free. That will do.
^ permalink raw reply
* Re: [PATCH] net/core: Save the port number a netdevice uses
From: Ben Hutchings @ 2010-06-02 16:42 UTC (permalink / raw)
To: David Miller
Cc: Eli Cohen, netdev, linux-rdma, Roland Dreier, Yevgeny Petrilin
In-Reply-To: <20100526.021635.179940939.davem@davemloft.net>
On Wed, 2010-05-26 at 02:16 -0700, David Miller wrote:
> From: Eli Cohen <eli@dev.mellanox.co.il>
> Date: Wed, 26 May 2010 12:08:52 +0300
>
> > So if I understand you correctly, you think that I should not bother
> > to set a default value of 1. Each driver that cares about the value
> > of this field, will set it however they want.
>
> I actually mean that the value "0" should mean the first port,
> the value "1" should mean the second port, etc.
There's a compatibility problem here though: when user-space looks at
this number it can't tell whether "0" really means the first port or
that the driver isn't setting dev_id. In order to tell that it would
have to check the driver or kernel version too, and this is really nasty
(what if the driver was backported?). So I think that 1-based numbering
for drivers that previously didn't set dev_id.
Why does this matter? I'm maintaining the firmware update program for
Solarflare NICs under Linux. Some of the firmware it updates is
per-port and some of it is per-board. It needs to be able to tell which
net and PCI devices are associated with the same board. At the moment
it works on the basis of PCI addresses, but this is unreliable in the
presence of virtualisation. It would be better to use board serial
number and the port identifier that I just changed the driver to use,
but since there are existing driver versions always leave dev_id = 0, I
it needs to be able to tell whether dev_id is meaningful.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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: sysfs class/net/ problem
From: Eric W. Biederman @ 2010-06-02 16:43 UTC (permalink / raw)
To: Johannes Berg; +Cc: Greg KH, netdev
In-Reply-To: <1275495677.3915.16.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Wed, 2010-06-02 at 09:17 -0700, Eric W. Biederman wrote:
>
>> >> Ah, so the network devices aren't getting removed?
>> >
>> > Well the netdevs are gone, just the links aren't going away. the
>> > mac80211_hwsim directory is gone too.
>> >
>> >> Do you have network namespaces enabled in your kernel or disabled?
>> >
>> > enabled
>> >
>> >> And this is 2.6.35-rc1, right?
>> >
>> > yes.
>> >
>> > Come to think of it, maybe somehow it ends up removing
>> > mac80211_hwsim/hwsim0 before wlan0, and thus the link stays around? I
>> > guess I could make it print messages about that somehow?
>>
>> The wireless drivers are a little different, and come to think of it
>> network namespace support has been added to the wireless drivers since
>> last I looked closely.
>
> Yeah, I now need to go add tagged sysfs support to it too.
>
>> Do you know what creates/deletes these links?
>> Is it the normal register_netdevice -> device_add path?
>
> Yes, they aren't done specially.
>> I definitely changed the symlink code a little making things network namespace
>> aware so it is reasonable to assume that something in my changes affected the
>> wireless drivers.
>
>> I took a quick look and with my patches against 2.6.33 I'm not seeing this.
>
> Hmm. I'm also not seeing it with veth, it would seem that ought to be
> similar?
Since it is the register_netdev path it should be exactly the same.
The big change I made is I in some instances I replaced
sysfs_remove_link with sysfs_delete_link so I could have enough
information to infer which network namespace the link was in. Since
wlan0 is a netdevice all of that information should already be there.
>> I take a closer look at 2.6.35-rc1 and see if I can figure out what is
>> going on. It would definitely be wrong if hwsim0 is removed before
>> wlan0.
>
> I don't know if that's happening .. just guessing that it might cause
> such a problem, and maybe some things are deferred somehow? Since netdev
> destruction can be deferred, but the wifi sysfs destruction isn't. But
> then that link there should cause the refcount to not go down until the
> link goes away>?
unregister_netdevice will defer the final destruction but it does not
defer netdev_unregister_kobject -> device_del.
What happens if in exit_mac80211_hwsim you call unregister_netdev before
mac80211_hwsim_free?
At a quick glance it simply looks like you have the ordering reversed in your
module cleanup, and this is not network namespace related at all.
Eric
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Christoph Lameter @ 2010-06-02 16:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, shemminger
In-Reply-To: <1275496439.2725.203.camel@edumazet-laptop>
On Wed, 2 Jun 2010, Eric Dumazet wrote:
> take a look at
>
> http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/html/SystemTap_Beginners_Guide/useful-systemtap-scripts.html#dropwatch
System tap? Oh no. Also skbs may be freed for legitimate reasons. The
point is that the loss detection needs to be usable for a regular mortal.
With the counters in /proc/net/snmp you have something that is easy to
handle.
The approach with systemtap will need lots of work to both get the tracing
environment setup (local competence in systemtap) and participation by a
developer to figure out what the output means. Then there is also the
additional code overhead that you do not want by default in the kernel. So
we would need a different kernel for diagnostics.
^ permalink raw reply
* Re: sysfs class/net/ problem
From: Johannes Berg @ 2010-06-02 17:00 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Greg KH, netdev
In-Reply-To: <m14ohlxu51.fsf@fess.ebiederm.org>
On Wed, 2010-06-02 at 09:43 -0700, Eric W. Biederman wrote:
> > Hmm. I'm also not seeing it with veth, it would seem that ought to be
> > similar?
>
> Since it is the register_netdev path it should be exactly the same.
>
> The big change I made is I in some instances I replaced
> sysfs_remove_link with sysfs_delete_link so I could have enough
> information to infer which network namespace the link was in. Since
> wlan0 is a netdevice all of that information should already be there.
I have no idea :)
> > I don't know if that's happening .. just guessing that it might cause
> > such a problem, and maybe some things are deferred somehow? Since netdev
> > destruction can be deferred, but the wifi sysfs destruction isn't. But
> > then that link there should cause the refcount to not go down until the
> > link goes away>?
>
> unregister_netdevice will defer the final destruction but it does not
> defer netdev_unregister_kobject -> device_del.
>
> What happens if in exit_mac80211_hwsim you call unregister_netdev before
> mac80211_hwsim_free?
>
> At a quick glance it simply looks like you have the ordering reversed in your
> module cleanup, and this is not network namespace related at all.
Nah, the unregister_netdev there removes the "hwsim0" device, while the
mac80211_hwsim_free() will remove all the others, so the ordering of
those two doesn't matter.
johannes
^ 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