* Re: [PATCH v3] vlan: Fix the ingress VLAN_FLAG_REORDER_HDR check
From: Jiri Pirko @ 2011-06-10 10:35 UTC (permalink / raw)
To: Changli Gao
Cc: David Miller, pratnakarlx, ebiederm, shemminger, greearb,
nicolas.2p.debian, netdev, kaber, fubar, eric.dumazet, andy,
jesse
In-Reply-To: <BANLkTimHi7V3YwbPepLyW7=pTS7hQVxEBQ@mail.gmail.com>
Fri, Jun 10, 2011 at 11:49:27AM CEST, xiaosuo@gmail.com wrote:
>On Fri, Jun 10, 2011 at 5:34 PM, Jiri Pirko <jpirko@redhat.com> wrote:
>> Fri, Jun 10, 2011 at 11:26:06AM CEST, xiaosuo@gmail.com wrote:
>>>On Fri, Jun 10, 2011 at 4:35 PM, Jiri Pirko <jpirko@redhat.com> wrote:
>>>> +
>>>> +/* Should be used only to revert vlan_reorder_header action */
>>>> +static struct sk_buff *vlan_unreorder_header(struct sk_buff *skb)
>>>> +{
>>>> + unsigned char *mac_header;
>>>> + struct vlan_ethhdr *veth;
>>>> +
>>>> + if (skb_cow(skb, skb_headroom(skb)) < 0)
>>>> + return NULL;
>>>
>>>I think we need to make sure if there is enough headroom for this
>>>header expansion.
>>
>> Well the header expansion was previously there so there should be place
>> there in all cases, or am I wrong?
>
>For hw-accel-vlan-rx, is the headroom for this header expansion
>reserved? I don't think so. Thanks.
But this wasn't done for hw-accel-vlan-rx previously right? So why don't
check for hw-accel-vlan-rx and don do unreorder in that case?
>
>--
>Regards,
>Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* [PATCH] net: DM9000: Add support for byte EEPROM access
From: Mark Brown @ 2011-06-10 10:50 UTC (permalink / raw)
Cc: netdev, Ben Dooks, Mark Brown
From: Ben Dooks <ben-linux@fluff.org>
Given many versions of ethtool's reluctance to do anything other than
byte accesses to the EEPROM interface, it is easier to update the driver
to support byte accesses so that all the ethtool versions that have been
observed in Debian can write the EEPROM.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/net/dm9000.c | 26 ++++++++++++++++++++------
1 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
index 863e9c4..8ef31dc 100644
--- a/drivers/net/dm9000.c
+++ b/drivers/net/dm9000.c
@@ -535,21 +535,35 @@ static int dm9000_set_eeprom(struct net_device *dev,
board_info_t *dm = to_dm9000_board(dev);
int offset = ee->offset;
int len = ee->len;
- int i;
+ int done;
/* EEPROM access is aligned to two bytes */
- if ((len & 1) != 0 || (offset & 1) != 0)
- return -EINVAL;
-
if (dm->flags & DM9000_PLATF_NO_EEPROM)
return -ENOENT;
if (ee->magic != DM_EEPROM_MAGIC)
return -EINVAL;
- for (i = 0; i < len; i += 2)
- dm9000_write_eeprom(dm, (offset + i) / 2, data + i);
+ while (len > 0) {
+ if (len & 1 || offset & 1) {
+ int which = offset & 1;
+ u8 tmp[2];
+
+ dm9000_read_eeprom(dm, offset / 2, tmp);
+ tmp[which] = *data;
+ dm9000_write_eeprom(dm, offset / 2, tmp);
+
+ done = 1;
+ } else {
+ dm9000_write_eeprom(dm, offset / 2, data);
+ done = 2;
+ }
+
+ data += done;
+ offset += done;
+ len -= done;
+ }
return 0;
}
--
1.7.5.3
^ permalink raw reply related
* [PATCH 0/3] Fixes for ARM/ebsa110 am79c961 driver
From: Russell King @ 2011-06-10 10:51 UTC (permalink / raw)
To: netdev
This series of patches fix some of the more serious issues discovered
with GCC 4 and the ARM EBSA110 am79c961 ethernet driver last weekend
while upgrading my firewall to 2.6.39.
--
Russell King
^ permalink raw reply
* [PATCH 1/3] NET: am79c961: ensure asm() statements are marked volatile
From: Russell King - ARM Linux @ 2011-06-10 10:51 UTC (permalink / raw)
To: netdev
In-Reply-To: <20110610105122.GA27087@flint.arm.linux.org.uk>
Without this the compiler can (and does) optimize register reads away
from within loops, and other such optimizations.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/net/arm/am79c961a.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/arm/am79c961a.c b/drivers/net/arm/am79c961a.c
index 0c9217f..084b67f 100644
--- a/drivers/net/arm/am79c961a.c
+++ b/drivers/net/arm/am79c961a.c
@@ -50,7 +50,7 @@ static const char version[] =
#ifdef __arm__
static void write_rreg(u_long base, u_int reg, u_int val)
{
- __asm__(
+ asm volatile(
"str%?h %1, [%2] @ NET_RAP\n\t"
"str%?h %0, [%2, #-4] @ NET_RDP"
:
@@ -60,7 +60,7 @@ static void write_rreg(u_long base, u_int reg, u_int val)
static inline unsigned short read_rreg(u_long base_addr, u_int reg)
{
unsigned short v;
- __asm__(
+ asm volatile(
"str%?h %1, [%2] @ NET_RAP\n\t"
"ldr%?h %0, [%2, #-4] @ NET_RDP"
: "=r" (v)
@@ -70,7 +70,7 @@ static inline unsigned short read_rreg(u_long base_addr, u_int reg)
static inline void write_ireg(u_long base, u_int reg, u_int val)
{
- __asm__(
+ asm volatile(
"str%?h %1, [%2] @ NET_RAP\n\t"
"str%?h %0, [%2, #8] @ NET_IDP"
:
@@ -80,7 +80,7 @@ static inline void write_ireg(u_long base, u_int reg, u_int val)
static inline unsigned short read_ireg(u_long base_addr, u_int reg)
{
u_short v;
- __asm__(
+ asm volatile(
"str%?h %1, [%2] @ NAT_RAP\n\t"
"ldr%?h %0, [%2, #8] @ NET_IDP\n\t"
: "=r" (v)
@@ -131,7 +131,7 @@ am_readbuffer(struct net_device *dev, u_int offset, unsigned char *buf, unsigned
length = (length + 1) & ~1;
if ((int)buf & 2) {
unsigned int tmp;
- __asm__ __volatile__(
+ asm volatile(
"ldr%?h %2, [%0], #4\n\t"
"str%?b %2, [%1], #1\n\t"
"mov%? %2, %2, lsr #8\n\t"
@@ -141,7 +141,7 @@ am_readbuffer(struct net_device *dev, u_int offset, unsigned char *buf, unsigned
}
while (length > 8) {
unsigned int tmp, tmp2, tmp3;
- __asm__ __volatile__(
+ asm volatile(
"ldr%?h %2, [%0], #4\n\t"
"ldr%?h %3, [%0], #4\n\t"
"orr%? %2, %2, %3, lsl #16\n\t"
@@ -155,7 +155,7 @@ am_readbuffer(struct net_device *dev, u_int offset, unsigned char *buf, unsigned
}
while (length > 0) {
unsigned int tmp;
- __asm__ __volatile__(
+ asm volatile(
"ldr%?h %2, [%0], #4\n\t"
"str%?b %2, [%1], #1\n\t"
"mov%? %2, %2, lsr #8\n\t"
--
1.7.4.4
^ permalink raw reply related
* [PATCH 2/3] NET: am79c961: ensure multicast filter is correctly set at open
From: Russell King - ARM Linux @ 2011-06-10 10:52 UTC (permalink / raw)
To: netdev
In-Reply-To: <20110610105122.GA27087@flint.arm.linux.org.uk>
We were clearing out the multicast filter whenever the interface was
upped, and not setting the mode bits correctly. This can cause
problems if there are any multicast addresses already set at this
point, or if ALLMULTI was set.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/net/arm/am79c961a.c | 77 ++++++++++++++++++++++--------------------
1 files changed, 40 insertions(+), 37 deletions(-)
diff --git a/drivers/net/arm/am79c961a.c b/drivers/net/arm/am79c961a.c
index 084b67f..79d88a0 100644
--- a/drivers/net/arm/am79c961a.c
+++ b/drivers/net/arm/am79c961a.c
@@ -196,6 +196,42 @@ am79c961_ramtest(struct net_device *dev, unsigned int val)
return errorcount;
}
+static void am79c961_mc_hash(char *addr, u16 *hash)
+{
+ if (addr[0] & 0x01) {
+ int idx, bit;
+ u32 crc;
+
+ crc = ether_crc_le(ETH_ALEN, addr);
+
+ idx = crc >> 30;
+ bit = (crc >> 26) & 15;
+
+ hash[idx] |= 1 << bit;
+ }
+}
+
+static unsigned int am79c961_get_rx_mode(struct net_device *dev, u16 *hash)
+{
+ unsigned int mode = MODE_PORT_10BT;
+
+ if (dev->flags & IFF_PROMISC) {
+ mode |= MODE_PROMISC;
+ memset(hash, 0xff, 4 * sizeof(*hash));
+ } else if (dev->flags & IFF_ALLMULTI) {
+ memset(hash, 0xff, 4 * sizeof(*hash));
+ } else {
+ struct netdev_hw_addr *ha;
+
+ memset(hash, 0, 4 * sizeof(*hash));
+
+ netdev_for_each_mc_addr(ha, dev)
+ am79c961_mc_hash(ha->addr, hash);
+ }
+
+ return mode;
+}
+
static void
am79c961_init_for_open(struct net_device *dev)
{
@@ -203,6 +239,7 @@ am79c961_init_for_open(struct net_device *dev)
unsigned long flags;
unsigned char *p;
u_int hdr_addr, first_free_addr;
+ u16 multi_hash[4], mode = am79c961_get_rx_mode(dev, multi_hash);
int i;
/*
@@ -218,16 +255,12 @@ am79c961_init_for_open(struct net_device *dev)
write_ireg (dev->base_addr, 2, 0x0000); /* MODE register selects media */
for (i = LADRL; i <= LADRH; i++)
- write_rreg (dev->base_addr, i, 0);
+ write_rreg (dev->base_addr, i, multi_hash[i - LADRL]);
for (i = PADRL, p = dev->dev_addr; i <= PADRH; i++, p += 2)
write_rreg (dev->base_addr, i, p[0] | (p[1] << 8));
- i = MODE_PORT_10BT;
- if (dev->flags & IFF_PROMISC)
- i |= MODE_PROMISC;
-
- write_rreg (dev->base_addr, MODE, i);
+ write_rreg (dev->base_addr, MODE, mode);
write_rreg (dev->base_addr, POLLINT, 0);
write_rreg (dev->base_addr, SIZERXR, -RX_BUFFERS);
write_rreg (dev->base_addr, SIZETXR, -TX_BUFFERS);
@@ -340,21 +373,6 @@ am79c961_close(struct net_device *dev)
return 0;
}
-static void am79c961_mc_hash(char *addr, unsigned short *hash)
-{
- if (addr[0] & 0x01) {
- int idx, bit;
- u32 crc;
-
- crc = ether_crc_le(ETH_ALEN, addr);
-
- idx = crc >> 30;
- bit = (crc >> 26) & 15;
-
- hash[idx] |= 1 << bit;
- }
-}
-
/*
* Set or clear promiscuous/multicast mode filter for this adapter.
*/
@@ -362,24 +380,9 @@ static void am79c961_setmulticastlist (struct net_device *dev)
{
struct dev_priv *priv = netdev_priv(dev);
unsigned long flags;
- unsigned short multi_hash[4], mode;
+ u16 multi_hash[4], mode = am79c961_get_rx_mode(dev, multi_hash);
int i, stopped;
- mode = MODE_PORT_10BT;
-
- if (dev->flags & IFF_PROMISC) {
- mode |= MODE_PROMISC;
- } else if (dev->flags & IFF_ALLMULTI) {
- memset(multi_hash, 0xff, sizeof(multi_hash));
- } else {
- struct netdev_hw_addr *ha;
-
- memset(multi_hash, 0x00, sizeof(multi_hash));
-
- netdev_for_each_mc_addr(ha, dev)
- am79c961_mc_hash(ha->addr, multi_hash);
- }
-
spin_lock_irqsave(&priv->chip_lock, flags);
stopped = read_rreg(dev->base_addr, CSR0) & CSR0_STOP;
--
1.7.4.4
^ permalink raw reply related
* [PATCH 3/3] NET: am79c961: fix assembler warnings
From: Russell King - ARM Linux @ 2011-06-10 10:52 UTC (permalink / raw)
To: netdev
In-Reply-To: <20110610105122.GA27087@flint.arm.linux.org.uk>
Fix:
/tmp/ccvoZ6h8.s: Assembler messages:
/tmp/ccvoZ6h8.s:284: Warning: register range not in ascending order
/tmp/ccvoZ6h8.s:881: Warning: register range not in ascending order
/tmp/ccvoZ6h8.s:1087: Warning: register range not in ascending order
by ensuring that we have temporary variables placed into specific
registers. Reorder the code a bit to allow the resulting assembly
to be slightly more optimal.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/net/arm/am79c961a.c | 35 ++++++++++++++++++-----------------
1 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/net/arm/am79c961a.c b/drivers/net/arm/am79c961a.c
index 79d88a0..7b3e23f 100644
--- a/drivers/net/arm/am79c961a.c
+++ b/drivers/net/arm/am79c961a.c
@@ -91,40 +91,41 @@ static inline unsigned short read_ireg(u_long base_addr, u_int reg)
#define am_writeword(dev,off,val) __raw_writew(val, ISAMEM_BASE + ((off) << 1))
#define am_readword(dev,off) __raw_readw(ISAMEM_BASE + ((off) << 1))
-static inline void
+static void
am_writebuffer(struct net_device *dev, u_int offset, unsigned char *buf, unsigned int length)
{
offset = ISAMEM_BASE + (offset << 1);
length = (length + 1) & ~1;
if ((int)buf & 2) {
- __asm__ __volatile__("str%?h %2, [%0], #4"
+ asm volatile("str%?h %2, [%0], #4"
: "=&r" (offset) : "0" (offset), "r" (buf[0] | (buf[1] << 8)));
buf += 2;
length -= 2;
}
while (length > 8) {
- unsigned int tmp, tmp2;
- __asm__ __volatile__(
- "ldm%?ia %1!, {%2, %3}\n\t"
+ register unsigned int tmp asm("r2"), tmp2 asm("r3");
+ asm volatile(
+ "ldm%?ia %0!, {%1, %2}"
+ : "+r" (buf), "=&r" (tmp), "=&r" (tmp2));
+ length -= 8;
+ asm volatile(
+ "str%?h %1, [%0], #4\n\t"
+ "mov%? %1, %1, lsr #16\n\t"
+ "str%?h %1, [%0], #4\n\t"
"str%?h %2, [%0], #4\n\t"
"mov%? %2, %2, lsr #16\n\t"
- "str%?h %2, [%0], #4\n\t"
- "str%?h %3, [%0], #4\n\t"
- "mov%? %3, %3, lsr #16\n\t"
- "str%?h %3, [%0], #4"
- : "=&r" (offset), "=&r" (buf), "=r" (tmp), "=r" (tmp2)
- : "0" (offset), "1" (buf));
- length -= 8;
+ "str%?h %2, [%0], #4"
+ : "+r" (offset), "=&r" (tmp), "=&r" (tmp2));
}
while (length > 0) {
- __asm__ __volatile__("str%?h %2, [%0], #4"
+ asm volatile("str%?h %2, [%0], #4"
: "=&r" (offset) : "0" (offset), "r" (buf[0] | (buf[1] << 8)));
buf += 2;
length -= 2;
}
}
-static inline void
+static void
am_readbuffer(struct net_device *dev, u_int offset, unsigned char *buf, unsigned int length)
{
offset = ISAMEM_BASE + (offset << 1);
@@ -140,12 +141,12 @@ am_readbuffer(struct net_device *dev, u_int offset, unsigned char *buf, unsigned
length -= 2;
}
while (length > 8) {
- unsigned int tmp, tmp2, tmp3;
+ register unsigned int tmp asm("r2"), tmp2 asm("r3"), tmp3;
asm volatile(
"ldr%?h %2, [%0], #4\n\t"
+ "ldr%?h %4, [%0], #4\n\t"
"ldr%?h %3, [%0], #4\n\t"
- "orr%? %2, %2, %3, lsl #16\n\t"
- "ldr%?h %3, [%0], #4\n\t"
+ "orr%? %2, %2, %4, lsl #16\n\t"
"ldr%?h %4, [%0], #4\n\t"
"orr%? %3, %3, %4, lsl #16\n\t"
"stm%?ia %1!, {%2, %3}"
--
1.7.4.4
^ permalink raw reply related
* [PATCH] virtio_net: introduce VIRTIO_NET_HDR_F_DATA_VALID
From: Jason Wang @ 2011-06-10 10:56 UTC (permalink / raw)
To: rusty, mst, davem, netdev, linux-kernel, virtualization
Cc: yvugenfi, kvm, herbert, Jason Wang
There's no need for the guest to validate the checksum if it have been
validated by host nics. So this patch introduces a new flag -
VIRTIO_NET_HDR_F_DATA_VALID which is used to bypass the checksum
examing in guest. The backend (tap/macvtap) may set this flag when
met skbs with CHECKSUM_UNNECESSARY to save cpu utilization.
No feature negotiation is needed as old driver just ignore this flag.
Iperf shows 12%-30% performance improvement for UDP traffic. For TCP,
when gro is on no difference as it produces skb with partial
checksum. But when gro is disabled, 20% or even higher improvement
could be measured by netperf.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/macvtap.c | 2 ++
drivers/net/tun.c | 2 ++
drivers/net/virtio_net.c | 2 ++
include/linux/virtio_net.h | 1 +
net/packet/af_packet.c | 2 ++
5 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 6696e56..ecee0fe 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -508,6 +508,8 @@ static int macvtap_skb_to_vnet_hdr(const struct sk_buff *skb,
vnet_hdr->flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;
vnet_hdr->csum_start = skb_checksum_start_offset(skb);
vnet_hdr->csum_offset = skb->csum_offset;
+ } else if (skb->ip_summed == CHECKSUM_UNNECESSARY) {
+ vnet_hdr->flags = VIRTIO_NET_HDR_F_DATA_VALID;
} /* else everything is zero */
return 0;
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 74e9405..f43fa45 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -788,6 +788,8 @@ static __inline__ ssize_t tun_put_user(struct tun_struct *tun,
gso.flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;
gso.csum_start = skb_checksum_start_offset(skb);
gso.csum_offset = skb->csum_offset;
+ } else if (skb->ip_summed == CHECKSUM_UNNECESSARY) {
+ gso.flags = VIRTIO_NET_HDR_F_DATA_VALID;
} /* else everything is zero */
if (unlikely(memcpy_toiovecend(iv, (void *)&gso, total,
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index f685324..be3686a 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -274,6 +274,8 @@ static void receive_buf(struct net_device *dev, void *buf, unsigned int len)
hdr->hdr.csum_start,
hdr->hdr.csum_offset))
goto frame_err;
+ } else if (hdr->hdr.flags & VIRTIO_NET_HDR_F_DATA_VALID) {
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
}
skb->protocol = eth_type_trans(skb, dev);
diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
index 136040b..970d5a2 100644
--- a/include/linux/virtio_net.h
+++ b/include/linux/virtio_net.h
@@ -63,6 +63,7 @@ struct virtio_net_config {
* specify GSO or CSUM features, you can simply ignore the header. */
struct virtio_net_hdr {
#define VIRTIO_NET_HDR_F_NEEDS_CSUM 1 // Use csum_start, csum_offset
+#define VIRTIO_NET_HDR_F_DATA_VALID 2 // Csum is valid
__u8 flags;
#define VIRTIO_NET_HDR_GSO_NONE 0 // Not a GSO frame
#define VIRTIO_NET_HDR_GSO_TCPV4 1 // GSO frame, IPv4 TCP (TSO)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index c0c3cda..99ca471 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1681,6 +1681,8 @@ static int packet_recvmsg(struct kiocb *iocb, struct socket *sock,
vnet_hdr.flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;
vnet_hdr.csum_start = skb_checksum_start_offset(skb);
vnet_hdr.csum_offset = skb->csum_offset;
+ } else if (skb->ip_summed == CHECKSUM_UNNECESSARY) {
+ vnet_hdr.flags = VIRTIO_NET_HDR_F_DATA_VALID;
} /* else everything is zero */
err = memcpy_toiovec(msg->msg_iov, (void *)&vnet_hdr,
--
1.7.1
^ permalink raw reply related
* CRC endianess problem on DGE-510T
From: Daniel Hellstrom @ 2011-06-10 8:03 UTC (permalink / raw)
To: netdev
Hello,
I'm having problems with the PCI network board D-LINK DGE-510T on
SPARC32/LEON. The CRC calculated by ether_crc_le() does not match the
CRC, however after swapping the result it matches. This is the same
behaviour with the 3 boards I have. After applying the patch below
everything works.
Does anyone know if this is a correct patch or has had similar problems
on big endian machines?
Daniel
From: Daniel Hellstrom <daniel@gaisler.com>
Date: Wed, 6 Apr 2011 15:01:44 +0200
[PATCH] dl2k: EEPROM CRC calculation wrong endianess on bigendian machine
Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
---
drivers/net/dl2k.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/dl2k.c b/drivers/net/dl2k.c
index c445457..4bbbd7b 100644
--- a/drivers/net/dl2k.c
+++ b/drivers/net/dl2k.c
@@ -346,7 +346,7 @@ parse_eeprom (struct net_device *dev)
if (np->pdev->vendor == PCI_VENDOR_ID_DLINK) { /* D-Link Only */
/* Check CRC */
crc = ~ether_crc_le (256 - 4, sromdata);
- if (psrom->crc != crc) {
+ if (psrom->crc != cpu_to_le32(crc)) {q
printk (KERN_ERR "%s: EEPROM data CRC error.\n",
dev->name);
return -1;
--
1.5.4
^ permalink raw reply related
* [PATCH net-next-2.6] be2net: Enable NETIF_F_TSO6 for VLAN traffic for BE
From: Padmanabh Ratnakar @ 2011-06-10 11:01 UTC (permalink / raw)
To: davem, netdev; +Cc: Padmanabh Ratnakar
NETIF_F_TSO6 for VLAN packets was not enabled for BE adapters.
Enabling it.
Signed-off-by: Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
---
drivers/net/benet/be_main.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 9ba197b..6ddaa34 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -2925,12 +2925,9 @@ static void be_netdev_init(struct net_device *netdev)
netdev->features |= netdev->hw_features |
NETIF_F_HW_VLAN_RX | NETIF_F_HW_VLAN_FILTER;
- netdev->vlan_features |= NETIF_F_SG | NETIF_F_TSO |
+ netdev->vlan_features |= NETIF_F_SG | NETIF_F_TSO | NETIF_F_TSO6 |
NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
- if (lancer_chip(adapter))
- netdev->vlan_features |= NETIF_F_TSO6;
-
netdev->flags |= IFF_MULTICAST;
/* Default settings for Rx and Tx flow control */
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH v3] vlan: Fix the ingress VLAN_FLAG_REORDER_HDR check
From: Changli Gao @ 2011-06-10 11:20 UTC (permalink / raw)
To: Jiri Pirko
Cc: David Miller, pratnakarlx, ebiederm, shemminger, greearb,
nicolas.2p.debian, netdev, kaber, fubar, eric.dumazet, andy,
jesse
In-Reply-To: <20110610103503.GD17568@minipsycho.redhat.com>
On Fri, Jun 10, 2011 at 6:35 PM, Jiri Pirko <jpirko@redhat.com> wrote:
> Fri, Jun 10, 2011 at 11:49:27AM CEST, xiaosuo@gmail.com wrote:
>>
>>For hw-accel-vlan-rx, is the headroom for this header expansion
>>reserved? I don't think so. Thanks.
>
> But this wasn't done for hw-accel-vlan-rx previously right? So why don't
> check for hw-accel-vlan-rx and don do unreorder in that case?
>
Yes, it wasn't done before. We want to make the behaviors of
hw-accel-vlan-rx and non-hw-accel-vlan-rx are the same. Is it your
original goal of your vlan-untag patch?
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH] virtio_net: introduce VIRTIO_NET_HDR_F_DATA_VALID
From: Michael S. Tsirkin @ 2011-06-10 11:28 UTC (permalink / raw)
To: Jason Wang
Cc: rusty, davem, netdev, linux-kernel, virtualization, yvugenfi, kvm,
herbert
In-Reply-To: <1307703377-3798-1-git-send-email-jasowang@redhat.com>
On Fri, Jun 10, 2011 at 06:56:17PM +0800, Jason Wang wrote:
> There's no need for the guest to validate the checksum if it have been
> validated by host nics. So this patch introduces a new flag -
> VIRTIO_NET_HDR_F_DATA_VALID which is used to bypass the checksum
> examing in guest. The backend (tap/macvtap) may set this flag when
> met skbs with CHECKSUM_UNNECESSARY to save cpu utilization.
>
> No feature negotiation is needed as old driver just ignore this flag.
This wasn't required by the spec, but maybe it should be.
> Iperf shows 12%-30% performance improvement for UDP traffic. For TCP,
> when gro is on no difference as it produces skb with partial
> checksum. But when gro is disabled, 20% or even higher improvement
> could be measured by netperf.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/net/macvtap.c | 2 ++
> drivers/net/tun.c | 2 ++
> drivers/net/virtio_net.c | 2 ++
> include/linux/virtio_net.h | 1 +
> net/packet/af_packet.c | 2 ++
> 5 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> index 6696e56..ecee0fe 100644
> --- a/drivers/net/macvtap.c
> +++ b/drivers/net/macvtap.c
> @@ -508,6 +508,8 @@ static int macvtap_skb_to_vnet_hdr(const struct sk_buff *skb,
> vnet_hdr->flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;
> vnet_hdr->csum_start = skb_checksum_start_offset(skb);
> vnet_hdr->csum_offset = skb->csum_offset;
> + } else if (skb->ip_summed == CHECKSUM_UNNECESSARY) {
> + vnet_hdr->flags = VIRTIO_NET_HDR_F_DATA_VALID;
> } /* else everything is zero */
>
> return 0;
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 74e9405..f43fa45 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -788,6 +788,8 @@ static __inline__ ssize_t tun_put_user(struct tun_struct *tun,
> gso.flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;
> gso.csum_start = skb_checksum_start_offset(skb);
> gso.csum_offset = skb->csum_offset;
> + } else if (skb->ip_summed == CHECKSUM_UNNECESSARY) {
> + gso.flags = VIRTIO_NET_HDR_F_DATA_VALID;
> } /* else everything is zero */
>
> if (unlikely(memcpy_toiovecend(iv, (void *)&gso, total,
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index f685324..be3686a 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -274,6 +274,8 @@ static void receive_buf(struct net_device *dev, void *buf, unsigned int len)
> hdr->hdr.csum_start,
> hdr->hdr.csum_offset))
> goto frame_err;
> + } else if (hdr->hdr.flags & VIRTIO_NET_HDR_F_DATA_VALID) {
> + skb->ip_summed = CHECKSUM_UNNECESSARY;
> }
>
> skb->protocol = eth_type_trans(skb, dev);
> diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
> index 136040b..970d5a2 100644
> --- a/include/linux/virtio_net.h
> +++ b/include/linux/virtio_net.h
> @@ -63,6 +63,7 @@ struct virtio_net_config {
> * specify GSO or CSUM features, you can simply ignore the header. */
> struct virtio_net_hdr {
> #define VIRTIO_NET_HDR_F_NEEDS_CSUM 1 // Use csum_start, csum_offset
> +#define VIRTIO_NET_HDR_F_DATA_VALID 2 // Csum is valid
> __u8 flags;
> #define VIRTIO_NET_HDR_GSO_NONE 0 // Not a GSO frame
> #define VIRTIO_NET_HDR_GSO_TCPV4 1 // GSO frame, IPv4 TCP (TSO)
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index c0c3cda..99ca471 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -1681,6 +1681,8 @@ static int packet_recvmsg(struct kiocb *iocb, struct socket *sock,
> vnet_hdr.flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;
> vnet_hdr.csum_start = skb_checksum_start_offset(skb);
> vnet_hdr.csum_offset = skb->csum_offset;
> + } else if (skb->ip_summed == CHECKSUM_UNNECESSARY) {
> + vnet_hdr.flags = VIRTIO_NET_HDR_F_DATA_VALID;
> } /* else everything is zero */
>
> err = memcpy_toiovec(msg->msg_iov, (void *)&vnet_hdr,
> --
> 1.7.1
^ permalink raw reply
* Re: [PATCH v3] vlan: Fix the ingress VLAN_FLAG_REORDER_HDR check
From: Jiri Pirko @ 2011-06-10 12:12 UTC (permalink / raw)
To: Changli Gao
Cc: David Miller, pratnakarlx, ebiederm, shemminger, greearb,
nicolas.2p.debian, netdev, kaber, fubar, eric.dumazet, andy,
jesse
In-Reply-To: <BANLkTinctdoyYJo+sU9qUWV8uZV8yGNdnw@mail.gmail.com>
Fri, Jun 10, 2011 at 01:20:29PM CEST, xiaosuo@gmail.com wrote:
>On Fri, Jun 10, 2011 at 6:35 PM, Jiri Pirko <jpirko@redhat.com> wrote:
>> Fri, Jun 10, 2011 at 11:49:27AM CEST, xiaosuo@gmail.com wrote:
>>>
>>>For hw-accel-vlan-rx, is the headroom for this header expansion
>>>reserved? I don't think so. Thanks.
>>
>> But this wasn't done for hw-accel-vlan-rx previously right? So why don't
>> check for hw-accel-vlan-rx and don do unreorder in that case?
>>
>
>Yes, it wasn't done before. We want to make the behaviors of
>hw-accel-vlan-rx and non-hw-accel-vlan-rx are the same. Is it your
>original goal of your vlan-untag patch?
You are correct. I just thought that since disabling reordering will be
most likely removed in near future, non-hw-accel-vlan-rx reorder disable
would not be needed.
>
>--
>Regards,
>Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH] net: DM9000: Add support for byte EEPROM access
From: Ben Hutchings @ 2011-06-10 12:24 UTC (permalink / raw)
To: Mark Brown; +Cc: netdev, Ben Dooks
In-Reply-To: <1307703032-20349-1-git-send-email-broonie@opensource.wolfsonmicro.com>
On Fri, 2011-06-10 at 11:50 +0100, Mark Brown wrote:
> From: Ben Dooks <ben-linux@fluff.org>
>
> Given many versions of ethtool's reluctance to do anything other than
> byte accesses to the EEPROM interface, it is easier to update the driver
> to support byte accesses so that all the ethtool versions that have been
> observed in Debian can write the EEPROM.
>
> Signed-off-by: Ben Dooks <ben-linux@fluff.org>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: CRC endianess problem on DGE-510T
From: Ben Hutchings @ 2011-06-10 12:35 UTC (permalink / raw)
To: Daniel Hellstrom; +Cc: netdev
In-Reply-To: <4DF1CFC2.5080101@gaisler.com>
On Fri, 2011-06-10 at 10:03 +0200, Daniel Hellstrom wrote:
> Hello,
>
> I'm having problems with the PCI network board D-LINK DGE-510T on
> SPARC32/LEON. The CRC calculated by ether_crc_le() does not match the
> CRC, however after swapping the result it matches. This is the same
> behaviour with the 3 boards I have. After applying the patch below
> everything works.
>
> Does anyone know if this is a correct patch or has had similar problems
> on big endian machines?
No idea about this hardware, but it looks reasonable - the contents of
the EEPROM are treated as being in little-endian order, except when
reading the CRC for comparison.
> Daniel
>
>
>
>
> From: Daniel Hellstrom <daniel@gaisler.com>
> Date: Wed, 6 Apr 2011 15:01:44 +0200
> [PATCH] dl2k: EEPROM CRC calculation wrong endianess on bigendian machine
>
> Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
> ---
> drivers/net/dl2k.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/dl2k.c b/drivers/net/dl2k.c
> index c445457..4bbbd7b 100644
> --- a/drivers/net/dl2k.c
> +++ b/drivers/net/dl2k.c
> @@ -346,7 +346,7 @@ parse_eeprom (struct net_device *dev)
> if (np->pdev->vendor == PCI_VENDOR_ID_DLINK) { /* D-Link Only */
> /* Check CRC */
> crc = ~ether_crc_le (256 - 4, sromdata);
> - if (psrom->crc != crc) {
> + if (psrom->crc != cpu_to_le32(crc)) {q
q?
Ben.
> printk (KERN_ERR "%s: EEPROM data CRC error.\n",
> dev->name);
> return -1;
> --
> 1.5.4
> --
> 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
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: KVM induced panic on 2.6.38[2367] & 2.6.39
From: Mark Lord @ 2011-06-10 12:37 UTC (permalink / raw)
To: Simon Horman
Cc: Brad Campbell, Eric Dumazet, Patrick McHardy, Bart De Schuymer,
kvm, linux-mm, linux-kernel, netdev, netfilter-devel
In-Reply-To: <20110610025249.GD643@verge.net.au>
On 11-06-09 10:52 PM, Simon Horman wrote:
> On Thu, Jun 09, 2011 at 01:02:13AM +0800, Brad Campbell wrote:
>> On 08/06/11 11:59, Eric Dumazet wrote:
>>
>>> Well, a bisection definitely should help, but needs a lot of time in
>>> your case.
>>
>> Yes. compile, test, crash, walk out to the other building to press
>> reset, lather, rinse, repeat.
>>
>> I need a reset button on the end of a 50M wire, or a hardware watchdog!
Something many of us don't realize is that nearly all Intel chipsets
have a built-in hardware watchdog timer. This includes chipset for
consumer desktop boards as well as the big iron server stuff.
It's the "i8xx_tco" driver in the kernel enables use of them:
modprobe i8xx_tco
Cheers
^ permalink raw reply
* [PATCH] iproute2: Check getline() return code correctly
From: Petr Sabata @ 2011-06-10 12:49 UTC (permalink / raw)
To: netdev; +Cc: Petr Sabata
The current implementation is always false, no matter what happens.
Signed-off-by: Petr Sabata <contyk@redhat.com>
---
lib/utils.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/utils.c b/lib/utils.c
index 1b42222..76cadea 100644
--- a/lib/utils.c
+++ b/lib/utils.c
@@ -702,7 +702,7 @@ ssize_t getcmdline(char **linep, size_t *lenp, FILE *in)
size_t len1 = 0;
size_t cc1;
- if ((cc1 = getline(&line1, &len1, in)) < 0) {
+ if ((cc1 = getline(&line1, &len1, in)) == (size_t)-1) {
fprintf(stderr, "Missing continuation line\n");
return cc1;
}
--
1.7.5.2
^ permalink raw reply related
* Re: CRC endianess problem on DGE-510T
From: Daniel Hellstrom @ 2011-06-10 13:12 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1307709301.22348.594.camel@localhost>
Ben Hutchings wrote:
>On Fri, 2011-06-10 at 10:03 +0200, Daniel Hellstrom wrote:
>
>
>>Hello,
>>
>>I'm having problems with the PCI network board D-LINK DGE-510T on
>>SPARC32/LEON. The CRC calculated by ether_crc_le() does not match the
>>CRC, however after swapping the result it matches. This is the same
>>behaviour with the 3 boards I have. After applying the patch below
>>everything works.
>>
>>Does anyone know if this is a correct patch or has had similar problems
>>on big endian machines?
>>
>>
>
>No idea about this hardware, but it looks reasonable - the contents of
>the EEPROM are treated as being in little-endian order, except when
>reading the CRC for comparison.
>
>
Ok, then I will submit my patch to the list.
The funny thing is that other vendors than DLINK doesn't check the CRC,
they might have tested it on a big endian machine... but it might just
be a coincidence.
Thanks,
Daniel
>
>
>>Daniel
>>
>>
>>
>>
>>From: Daniel Hellstrom <daniel@gaisler.com>
>>Date: Wed, 6 Apr 2011 15:01:44 +0200
>>[PATCH] dl2k: EEPROM CRC calculation wrong endianess on bigendian machine
>>
>>Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
>>---
>> drivers/net/dl2k.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>>diff --git a/drivers/net/dl2k.c b/drivers/net/dl2k.c
>>index c445457..4bbbd7b 100644
>>--- a/drivers/net/dl2k.c
>>+++ b/drivers/net/dl2k.c
>>@@ -346,7 +346,7 @@ parse_eeprom (struct net_device *dev)
>> if (np->pdev->vendor == PCI_VENDOR_ID_DLINK) { /* D-Link Only */
>> /* Check CRC */
>> crc = ~ether_crc_le (256 - 4, sromdata);
>>- if (psrom->crc != crc) {
>>+ if (psrom->crc != cpu_to_le32(crc)) {q
>>
>>
>
>q?
>
>Ben.
>
>
>
>> printk (KERN_ERR "%s: EEPROM data CRC error.\n",
>> dev->name);
>> return -1;
>>--
>>1.5.4
>>--
>>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
* [PATCH 1/1] dl2k: EEPROM CRC calculation wrong endianess on bigendian machine
From: Daniel Hellstrom @ 2011-06-10 13:16 UTC (permalink / raw)
To: davem; +Cc: netdev, bhutchings
Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
---
drivers/net/dl2k.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/dl2k.c b/drivers/net/dl2k.c
index c445457..4bbbd7b 100644
--- a/drivers/net/dl2k.c
+++ b/drivers/net/dl2k.c
@@ -346,7 +346,7 @@ parse_eeprom (struct net_device *dev)
if (np->pdev->vendor == PCI_VENDOR_ID_DLINK) { /* D-Link Only */
/* Check CRC */
crc = ~ether_crc_le (256 - 4, sromdata);
- if (psrom->crc != crc) {
+ if (psrom->crc != cpu_to_le32(crc)) {q
printk (KERN_ERR "%s: EEPROM data CRC error.\n",
dev->name);
return -1;
--
1.5.4
^ permalink raw reply related
* [PATCH] iproute2: Remove unreachable code
From: Petr Sabata @ 2011-06-10 13:19 UTC (permalink / raw)
To: netdev; +Cc: Petr Sabata
This patch removes unreachable, useless code.
Signed-off-by: Petr Sabata <contyk@redhat.com>
---
genl/genl.c | 6 ------
tc/f_cgroup.c | 1 -
tc/q_drr.c | 3 +--
tc/q_multiq.c | 3 +--
4 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/genl/genl.c b/genl/genl.c
index 3ae75ae..7ec24eb 100644
--- a/genl/genl.c
+++ b/genl/genl.c
@@ -150,12 +150,6 @@ int main(int argc, char **argv)
ret = a->parse_genlopt(a, argc-1, argv+1);
return ret;
-
- if (matches(argv[1], "help") == 0)
- usage();
- fprintf(stderr, "Object \"%s\" is unknown, try \"genl "
- "-help\".\n", argv[1]);
- exit(-1);
}
usage();
diff --git a/tc/f_cgroup.c b/tc/f_cgroup.c
index 192e697..4a4026e 100644
--- a/tc/f_cgroup.c
+++ b/tc/f_cgroup.c
@@ -74,7 +74,6 @@ static int cgroup_parse_opt(struct filter_util *qu, char *handle,
explain();
return -1;
}
- argc--; argv++;
}
tail->rta_len = (((void*)n)+n->nlmsg_len) - (void*)tail;
diff --git a/tc/q_drr.c b/tc/q_drr.c
index 81de44d..9d3788f 100644
--- a/tc/q_drr.c
+++ b/tc/q_drr.c
@@ -36,7 +36,7 @@ static void explain2(void)
static int drr_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct nlmsghdr *n)
{
- while (argc > 0) {
+ while (argc) {
if (strcmp(*argv, "help") == 0) {
explain();
return -1;
@@ -45,7 +45,6 @@ static int drr_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct nl
explain();
return -1;
}
- argc--; argv++;
}
return 0;
}
diff --git a/tc/q_multiq.c b/tc/q_multiq.c
index fce5e44..7ff9e74 100644
--- a/tc/q_multiq.c
+++ b/tc/q_multiq.c
@@ -46,7 +46,7 @@ static int multiq_parse_opt(struct qdisc_util *qu, int argc, char **argv,
{
struct tc_multiq_qopt opt;
- if (argc > 0) {
+ if (argc) {
if (strcmp(*argv, "help") == 0) {
explain();
return -1;
@@ -55,7 +55,6 @@ static int multiq_parse_opt(struct qdisc_util *qu, int argc, char **argv,
explain();
return -1;
}
- argc--; argv++;
}
addattr_l(n, 1024, TCA_OPTIONS, &opt, sizeof(opt));
--
1.7.5.2
^ permalink raw reply related
* [PATCH net-next] net: fix MIPS fallout from "net: remove interrupt.h inclusion from netdevice.h"
From: Alexey Dobriyan @ 2011-06-10 13:36 UTC (permalink / raw)
To: davem; +Cc: netdev
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
drivers/net/bcm63xx_enet.c | 1 +
drivers/net/cpmac.c | 1 +
drivers/net/mipsnet.c | 1 +
drivers/net/octeon/octeon_mgmt.c | 1 +
4 files changed, 4 insertions(+)
--- a/drivers/net/bcm63xx_enet.c
+++ b/drivers/net/bcm63xx_enet.c
@@ -18,6 +18,7 @@
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
#include <linux/init.h>
+#include <linux/interrupt.h>
#include <linux/module.h>
#include <linux/clk.h>
#include <linux/etherdevice.h>
--- a/drivers/net/cpmac.c
+++ b/drivers/net/cpmac.c
@@ -18,6 +18,7 @@
#include <linux/module.h>
#include <linux/init.h>
+#include <linux/interrupt.h>
#include <linux/moduleparam.h>
#include <linux/sched.h>
--- a/drivers/net/mipsnet.c
+++ b/drivers/net/mipsnet.c
@@ -5,6 +5,7 @@
*/
#include <linux/init.h>
+#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/kernel.h>
#include <linux/module.h>
--- a/drivers/net/octeon/octeon_mgmt.c
+++ b/drivers/net/octeon/octeon_mgmt.c
@@ -9,6 +9,7 @@
#include <linux/capability.h>
#include <linux/dma-mapping.h>
#include <linux/init.h>
+#include <linux/interrupt.h>
#include <linux/platform_device.h>
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
^ permalink raw reply
* [PATCH 1/1] cdc_ncm: Fix TCP Window Size issue by CDC NCM driver
From: Elof Vrigborn @ 2011-06-10 13:39 UTC (permalink / raw)
To: Oliver Neukum; +Cc: netdev, Elof Vrigborn
CDC NCM driver clones SKBs for received data and update SKB
members of the clones according to received frames.
If SKB clone len member is updated but truesize member is not, it
could cause check #2 of the tcp_grow_window function to increase
the TCP window by the __tcp_grow_window function instead of the
expected increment by 2*advmss. This could to a great extent
limit the rcv_ssthres and by that the advertised TCP Window Size,
and in the end the data rate of a TCP connection, as according to
the TCP Sliding Window concept.
With this patch the truesize member of the SKB clones is updated
in similarity to the len member and by this the expected incremental
of the advertised TCP Window Size is seen and the TCP connection
data rate will not be unnecessarily limited.
Signed-off-by: Elof Vrigborn <elof.vrigborn@ericsson.com>
---
drivers/net/usb/cdc_ncm.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index f33ca6a..09923cd 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1083,6 +1083,7 @@ static int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in)
if (!skb)
goto error;
skb->len = temp;
+ skb->truesize = temp + sizeof(struct sk_buff);
skb->data = ((u8 *)skb_in->data) + offset;
skb_set_tail_pointer(skb, temp);
usbnet_skb_return(dev, skb);
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH 1/1] dl2k: EEPROM CRC calculation wrong endianess on bigendian machine
From: Ben Hutchings @ 2011-06-10 13:49 UTC (permalink / raw)
To: Daniel Hellstrom; +Cc: davem, netdev
In-Reply-To: <1307711777-12119-1-git-send-email-daniel@gaisler.com>
On Fri, 2011-06-10 at 15:16 +0200, Daniel Hellstrom wrote:
> Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
> ---
> drivers/net/dl2k.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/dl2k.c b/drivers/net/dl2k.c
> index c445457..4bbbd7b 100644
> --- a/drivers/net/dl2k.c
> +++ b/drivers/net/dl2k.c
> @@ -346,7 +346,7 @@ parse_eeprom (struct net_device *dev)
> if (np->pdev->vendor == PCI_VENDOR_ID_DLINK) { /* D-Link Only */
> /* Check CRC */
> crc = ~ether_crc_le (256 - 4, sromdata);
> - if (psrom->crc != crc) {
> + if (psrom->crc != cpu_to_le32(crc)) {q
You still have a rogue 'q' there.
Ben.
> printk (KERN_ERR "%s: EEPROM data CRC error.\n",
> dev->name);
> return -1;
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: TCP keepalives ignored by kernel when the contain timestamps
From: Eric Dumazet @ 2011-06-10 13:56 UTC (permalink / raw)
To: Charles Bearden; +Cc: netdev
In-Reply-To: <4DF0E638.2010506@uth.tmc.edu>
Le jeudi 09 juin 2011 à 10:26 -0500, Charles Bearden a écrit :
> I have come across a case that looks like it might be a kernel bug. It appears
> that tcp keepalives sent by a remote system are ignored when they contain tcp
> timestamps, but are ACKed when they don't. When they are ignored, the remote
> system resets the connection after a number of retries.
>
> I have replicated this problem on both Ubuntu 10.04 with a 2.6.32-32-server
> kernel (x86_64) and CentOS 5.6 with a 2.6.18-238.12.1.el5 kernel. I'm sorry that
> I haven't had a chance to try to replicate the bug with a newer kernel, though a
> co-worker has looked through changelogs for more recent kernels and didn't find
> anything that looked relevant.
>
> From either of these hosts I run an application that connects to a remote host
> for 2-3 minutes, and that for most of that time sends no application data back
> and forth. After 30 seconds of no data from the Linux host, the remote host
> sends a garden variety keepalive. When the remote host includes tcp timestamps
> in the keepalives, they are ignored by the Linux host, and the remote host
> resets the connection after 10 unACKed keepalives. When timestamps are absent
> from the keepalives, the Linux host ACKs each one, and all is copacetic.
>
> Text output of a tcpdump trace of a connection that fails:
> http://pastebin.com/v6CpteJ9
>
> Text output of a tcpdump trace of a connection that succeeds:
> http://pastebin.com/KVLb3Mzh
>
> More details, in case you think they are relevant:
>
> My application creates a JDBC connection to a remote MS SQL Server and
> executes a statement that does not return a result set, and so it doesn't
> need to pass application data back and forth while it executes. The
> statement takes 2 or 3 minutes to complete. I connect to two different
> remote hosts: a Win2003 machine, and a Win2008R2 machine. The Win2003
> machine doesn't put timestamps in its keep-alives, so the application
> completes successfully when connecting to that host. If tcp timestamps
> are enabled on the Linux host, the Win2008 host includes them in its
> keepalives, and they are unACKed, so the connection is reset; if they
> are disabled on the Linux host, the Win2008 host doesn't include them in
> the keepalives, and the application completes successfully. I use (as
> you might expect) sysctl to disable tcp timestamps on the Linux hosts.
>
> I have dumps for all permutations of CentOS/Ubuntu, Win200[38], and +/-
> timestamps on the Linux side, and I will post them if the developers think that
> they would be useful.
Hi Charles
I could not reproduce the problem here, even using a quite old kernel as
receiver (2.6.9)
15:54:33.566192 IP 192.168.20.108.55926 > 192.168.20.124.777: SWE
479814493:479814493(0) win 14600 <mss 1460,sackOK,timestamp 151666
0,nop,wscale 7>
15:54:33.566265 IP 192.168.20.124.777 > 192.168.20.108.55926: S
3714869381:3714869381(0) ack 479814494 win 5792 <mss
1460,sackOK,timestamp 54553041 151666,nop,wscale 2>
15:54:33.566274 IP 192.168.20.108.55926 > 192.168.20.124.777: . ack 1
win 115 <nop,nop,timestamp 151666 54553041>
15:54:33.566281 IP 192.168.20.108.55926 > 192.168.20.124.777: P 1:5(4)
ack 1 win 115 <nop,nop,timestamp 151666 54553041>
15:54:33.566351 IP 192.168.20.124.777 > 192.168.20.108.55926: . ack 5
win 1448 <nop,nop,timestamp 54553041 151666>
15:54:33.566375 IP 192.168.20.124.777 > 192.168.20.108.55926: P 1:5(4)
ack 5 win 1448 <nop,nop,timestamp 54553041 151666>
15:54:33.566380 IP 192.168.20.108.55926 > 192.168.20.124.777: . ack 5
win 115 <nop,nop,timestamp 151666 54553041>
15:54:43.577945 IP 192.168.20.108.55926 > 192.168.20.124.777: . 4:5(1)
ack 5 win 115 <nop,nop,timestamp 152668 54553041>
15:54:43.578012 IP 192.168.20.124.777 > 192.168.20.108.55926: . ack 5
win 1448 <nop,nop,timestamp 54563053 152668,nop,nop,sack sack 1 {4:5} >
15:54:53.597946 IP 192.168.20.108.55926 > 192.168.20.124.777: . 4:5(1)
ack 5 win 115 <nop,nop,timestamp 153670 54563053>
15:54:53.598012 IP 192.168.20.124.777 > 192.168.20.108.55926: . ack 5
win 1448 <nop,nop,timestamp 54573073 153670,nop,nop,sack sack 1 {4:5} >
Are you sure frame tcp checksums are OK when the 'faulty' linux receive
them ? (tcpdump -v)
^ permalink raw reply
* Re: [PATCH 1/1] cdc_ncm: Fix TCP Window Size issue by CDC NCM driver
From: Eric Dumazet @ 2011-06-10 14:10 UTC (permalink / raw)
To: Elof Vrigborn; +Cc: Oliver Neukum, netdev
In-Reply-To: <1307713174-533-1-git-send-email-elof.vrigborn@ericsson.com>
Le vendredi 10 juin 2011 à 15:39 +0200, Elof Vrigborn a écrit :
> CDC NCM driver clones SKBs for received data and update SKB
> members of the clones according to received frames.
>
> If SKB clone len member is updated but truesize member is not, it
> could cause check #2 of the tcp_grow_window function to increase
> the TCP window by the __tcp_grow_window function instead of the
> expected increment by 2*advmss. This could to a great extent
> limit the rcv_ssthres and by that the advertised TCP Window Size,
> and in the end the data rate of a TCP connection, as according to
> the TCP Sliding Window concept.
>
> With this patch the truesize member of the SKB clones is updated
> in similarity to the len member and by this the expected incremental
> of the advertised TCP Window Size is seen and the TCP connection
> data rate will not be unnecessarily limited.
>
> Signed-off-by: Elof Vrigborn <elof.vrigborn@ericsson.com>
> ---
> drivers/net/usb/cdc_ncm.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
> index f33ca6a..09923cd 100644
> --- a/drivers/net/usb/cdc_ncm.c
> +++ b/drivers/net/usb/cdc_ncm.c
> @@ -1083,6 +1083,7 @@ static int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in)
> if (!skb)
> goto error;
> skb->len = temp;
> + skb->truesize = temp + sizeof(struct sk_buff);
> skb->data = ((u8 *)skb_in->data) + offset;
> skb_set_tail_pointer(skb, temp);
> usbnet_skb_return(dev, skb);
I find this patch dubious.
skb truesize is not meant to be skb->len + sizeof(struct sk_buff);
truesize is really accounting for the truesize of memory blocks, not the
used one.
Many drivers allocate a full 2Kbyte block, even if only 100 bytes are
used in it. If we want to reduce "truesize", then we perform a
"copybreak", to allocate a right sized skb. Some NICS do that for small
frames.
If you have TCP performance problems, this might be because of another
high level problem. This truesize underestimation is only hiding the
problem, but makes the whole machine more subject to OOM bugs.
Could you provide more information ?
^ permalink raw reply
* tc match MAC destination
From: Andrei Popa @ 2011-06-10 14:18 UTC (permalink / raw)
To: netdev; +Cc: pdoru.kernel
Hello,
I want to shape PVSTP+ traffic (traffic that has MAC destination
01:00:0c:cc:cc:cd) and it doesn't work.
I've tried
filter parent 1: protocol 802_3 pref 2 u32 fh 802::11 order 17 key ht
802 bkt 0 flowid 1:3
match 01000ccc/ffffffff at 0
but it doesn't work.
With
filter parent 1: protocol arp pref 1 u32
filter parent 1: protocol arp pref 1 u32 fh 801: ht divisor 1
filter parent 1: protocol arp pref 1 u32 fh 801::7 order 7 key ht 801
bkt 0 flowid 1:3
match 00000000/00000000 at 0
filter parent 1: protocol 802_3 pref 2 u32
filter parent 1: protocol 802_3 pref 2 u32 fh 802: ht divisor 1
filter parent 1: protocol 802_3 pref 2 u32 fh 802::3 order 3 key ht 802
bkt 0 flowid 1:3
match 00000000/00000000 at 0
action order 1: mirred (Egress Mirror to device ifb1) pipe
index 1923 ref 1 bind 1
I see arp trafic with tcpdump on ifb1, but no STP traffic or any kind of
traffic except arp, because I've matched all MAC addreses.
Can somebody verify that this match works ?
I use kernel 2.6.39.1.
Thank you,
--
Andrei Popa
0760 683 280
^ 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