* Re: [PATCH 0/2] tun: linux socket filter support
From: David Miller @ 2010-02-18 0:35 UTC (permalink / raw)
To: mst; +Cc: herbert, paul.moore, David.Woodhouse, sri, netdev, linux-kernel
In-Reply-To: <20100214110051.GA30182@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Sun, 14 Feb 2010 13:00:51 +0200
> tun module already support RX filtering, however,
> this is limited to filtering by mac address.
> For virtio host, we also need filtering by vlan.
>
> Rather than adding this directly, it seems cleaner
> to add generic socket filter support.
Both applied to net-next-2.6, thanks!
^ permalink raw reply
* Re: [net-next PATCH v4 3/3] net: TCP thin dupack
From: David Miller @ 2010-02-18 0:33 UTC (permalink / raw)
To: apetlund
Cc: netdev, ilpo.jarvinen, eric.dumazet, hannemann, linux-kernel,
shemminger, william.allen.simpson, damian, ebiederm
In-Reply-To: <4B7AAE6E.7080600@simula.no>
From: Andreas Petlund <apetlund@simula.no>
Date: Tue, 16 Feb 2010 15:40:46 +0100
> Major changes:
> -Renamed variables, ioctl and sysctl.
> -Added sysctl documentation.
> -Removed redundant allocation
>
> Signed-off-by: Andreas Petlund <apetlund@simula.no>
Patches #2 and #3 look the same, what's going on here?
Thanks.
^ permalink raw reply
* Re: [net-next PATCH v4 2/3] net: TCP thin linear timeouts
From: David Miller @ 2010-02-18 0:32 UTC (permalink / raw)
To: apetlund
Cc: netdev, ilpo.jarvinen, eric.dumazet, hannemann, linux-kernel,
shemminger, william.allen.simpson, damian, ebiederm
In-Reply-To: <4B7AAE69.8020701@simula.no>
From: Andreas Petlund <apetlund@simula.no>
Date: Tue, 16 Feb 2010 15:40:41 +0100
> @@ -341,6 +342,8 @@ struct tcp_sock {
> u16 advmss; /* Advertised MSS */
> u8 frto_counter; /* Number of new acks after RTO */
> u8 nonagle; /* Disable Nagle algorithm? */
> + u8 thin_lto : 1,/* Use linear timeouts for thin streams */
> + thin_undef : 7;
>
There is now a gap of 3 unused bytes here in this critical
core TCP socket data structure.
Please either find a way to avoid this hole, or document
it with a comment.
^ permalink raw reply
* Re: [net-next PATCH v4 1/3] net: TCP thin-stream detection
From: David Miller @ 2010-02-18 0:32 UTC (permalink / raw)
To: apetlund
Cc: netdev, ilpo.jarvinen, eric.dumazet, hannemann, linux-kernel,
shemminger, william.allen.simpson, damian, ebiederm
In-Reply-To: <4B7AAE60.3070305@simula.no>
From: Andreas Petlund <apetlund@simula.no>
Date: Tue, 16 Feb 2010 15:40:32 +0100
>
> +/* Determines whether this is a thin stream (which may suffer from
> + * increased latency). Used to trigger latency-reducing mechanisms.*/
> +static inline unsigned int tcp_stream_is_thin(struct tcp_sock *tp)
> +{
> + return tp->packets_out < 4 && !tcp_in_initial_slowstart(tp);
> +}
> +
> /* /proc */
Please format comments:
/* Like this. */
or:
/* Like this.
* And this.
*/
Thanks.
^ permalink raw reply
* Re: regression due to "flush SAD/SPD generate false events"
From: jamal @ 2010-02-18 0:03 UTC (permalink / raw)
To: David Miller; +Cc: adobriyan, netdev
In-Reply-To: <20100217.155512.109075614.davem@davemloft.net>
On Wed, 2010-02-17 at 15:55 -0800, David Miller wrote:
> I don't think any sendmsg() method should return 0 when something
> was actually sent.
;-> Ok, I need to call it a day ;->
cheers,
jamal
^ permalink raw reply
* Re: [net-next-2.6 PATCH] cxgb3: convert to use netdev_for_each_addr
From: David Miller @ 2010-02-18 0:03 UTC (permalink / raw)
To: jpirko; +Cc: netdev, divy
In-Reply-To: <20100217222714.GF2635@psychotron.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Wed, 17 Feb 2010 23:27:14 +0100
> Removed whole t3_rx_mode structure and appropriate helpers cause they are no
> longer needed.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] chelsio: convert to use netdev_for_each_mc_addr
From: David Miller @ 2010-02-18 0:03 UTC (permalink / raw)
To: jpirko; +Cc: netdev
In-Reply-To: <20100217215645.GD2635@psychotron.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Wed, 17 Feb 2010 22:56:45 +0100
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Applied.
^ permalink raw reply
* Re: [PACH] smsc911x: replace manual phy lookup.
From: David Miller @ 2010-02-18 0:03 UTC (permalink / raw)
To: "kirjanov, kirjanov; +Cc: steve.glendinning, jpirko, netdev
In-Reply-To: <20100217075458.GA4388@coldcone>
From: "Denis Kirjanov <kirjanov@gmail.com" <kirjanov@gmail.com>
Date: Wed, 17 Feb 2010 10:54:58 +0300
> Use phy_find_first() function instead of manual lookup.
>
> Signed-off-by: Denis Kirjanov <kirjanov@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] mv643xx_eth: fix missing validate_addr hook
From: David Miller @ 2010-02-18 0:03 UTC (permalink / raw)
To: "kirjanov, kirjanov; +Cc: netdev
In-Reply-To: <20100217064011.GA4132@coldcone>
From: "Denis Kirjanov <kirjanov@gmail.com" <kirjanov@gmail.com>
Date: Wed, 17 Feb 2010 09:40:11 +0300
> Fix missing validate_addr hook.
>
> Signed-off-by: Denis Kirjanov <kirjanov@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6] net: bug fix for vlan + gro issue
From: David Miller @ 2010-02-18 0:02 UTC (permalink / raw)
To: ajitk, ajitkhaparde; +Cc: herbert, kaber, netdev
In-Reply-To: <20100217062541.GA10350@serverengines.com>
From: Ajit Khaparde <ajitkhaparde@gmail.com>
Date: Wed, 17 Feb 2010 11:55:43 +0530
> Thanks Herbert. I think you meant something like this:
> + skb->protocol = eth_type_trans(skb, skb->dev);
>
> Here is the patch:-
>
> Traffic (tcp) doesnot start on a vlan interface when gro is enabled.
> Even the tcp handshake was not taking place.
> This is because, the eth_type_trans call before the netif_receive_skb
> in napi_gro_finish() resets the skb->dev to napi->dev from the previously
> set vlan netdev interface. This causes the ip_route_input to drop the
> incoming packet considering it as a packet coming from a martian source.
>
> I could repro this on 2.6.32.7 (stable) and 2.6.33-rc7.
> With this fix, the traffic starts and the test runs fine on both vlan
> and non-vlan interfaces.
>
> CC: Herbert Xu <herbert@gondor.apana.org.au>
> CC: Patrick McHardy <kaber@trash.net>
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/1 V6] net: Add Aeroflex Gaisler 10/100/1G Ethernet MAC driver
From: David Miller @ 2010-02-18 0:02 UTC (permalink / raw)
To: kristoffer; +Cc: netdev
In-Reply-To: <1266240824-535-2-git-send-email-kristoffer@gaisler.com>
From: Kristoffer Glembo <kristoffer@gaisler.com>
Date: Mon, 15 Feb 2010 14:33:44 +0100
> Adds device driver for Aeroflex Gaisler 10/100 and 10/100/1G Ethernet MAC IP cores.
>
> Signed-off-by: Kristoffer Glembo <kristoffer@gaisler.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH] via-velocity: Enable scatter/gather IO by default
From: David Miller @ 2010-02-18 0:01 UTC (permalink / raw)
To: simon.kagstrom; +Cc: netdev, krkumar2
In-Reply-To: <20100211163955.1b1dbe2c@marrow.netinsight.se>
From: Simon Kagstrom <simon.kagstrom@netinsight.net>
Date: Thu, 11 Feb 2010 16:39:55 +0100
> Reduces CPU utilization significantly with sendfile for example.
>
> Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
Applied.
^ permalink raw reply
* Re: regression due to "flush SAD/SPD generate false events"
From: David Miller @ 2010-02-17 23:55 UTC (permalink / raw)
To: hadi; +Cc: adobriyan, netdev
In-Reply-To: <1266450553.17794.165.camel@bigi>
From: jamal <hadi@cyberus.ca>
Date: Wed, 17 Feb 2010 18:49:13 -0500
> On Wed, 2010-02-17 at 15:40 -0800, David Miller wrote:
>
>> Please do, your changes are reverted so I need the whole
>> thing back.
>
> np.
> Q: Something odd i noticed when looking at pfkey (different behavior
> from netlink):
>
> pfkey_sendmsg() does at the end:
> return err ? : len;
>
> So if err was 0, it will always return the length which is
> 16 in the flush which was causing the EAGAIN Alexey saw. If i returned
> the correct error (ESRCH), it goes unfiltered.
> It sounds to me that should just unconditionaly return err, no?
I don't think any sendmsg() method should return 0 when something
was actually sent.
^ permalink raw reply
* Re: [PATCH v4 4/7] tcp: input header length, prediction, and timestamp bugs
From: David Miller @ 2010-02-17 23:50 UTC (permalink / raw)
To: william.allen.simpson; +Cc: linux-kernel, netdev, akpm, andi
In-Reply-To: <4B77966F.1030203@gmail.com>
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Sun, 14 Feb 2010 01:21:35 -0500
> Don't use output calculated tp->tcp_header_len for input decisions.
> While the output header is usually the same as the input (same options
> in both directions), that's a poor assumption. In particular, Sack
> will
> be different. Newer options are not guaranteed.
And when SACK is present, tp->tcp_header_len will not match, and
therefore we won't do the header prediction fast path, what is what we
want.
And, SACK presence doesn't change tp->tcp_header_len on transmit.
Therefore, I see no need at all for this change.
^ permalink raw reply
* Re: regression due to "flush SAD/SPD generate false events"
From: jamal @ 2010-02-17 23:49 UTC (permalink / raw)
To: David Miller; +Cc: adobriyan, netdev
In-Reply-To: <20100217.154009.78177059.davem@davemloft.net>
On Wed, 2010-02-17 at 15:40 -0800, David Miller wrote:
> Please do, your changes are reverted so I need the whole
> thing back.
np.
Q: Something odd i noticed when looking at pfkey (different behavior
from netlink):
pfkey_sendmsg() does at the end:
return err ? : len;
So if err was 0, it will always return the length which is
16 in the flush which was causing the EAGAIN Alexey saw. If i returned
the correct error (ESRCH), it goes unfiltered.
It sounds to me that should just unconditionaly return err, no?
cheers,
jamal
^ permalink raw reply
* Re: [PATCH v5 3/7] tcp: harmonize tcp_vx_rcv header length assumptions
From: David Miller @ 2010-02-17 23:47 UTC (permalink / raw)
To: william.allen.simpson; +Cc: linux-kernel, netdev, akpm, andi
In-Reply-To: <4B77953C.7070908@gmail.com>
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Sun, 14 Feb 2010 01:16:28 -0500
> @@ -1559,7 +1559,8 @@ int tcp_v4_do_rcv(struct sock *sk, struct sk_buff *skb)
> return 0;
> }
>
> - if (skb->len < tcp_hdrlen(skb) || tcp_checksum_complete(skb))
> + /* Assumes header and options unchanged since checksum_init() */
> + if (tcp_checksum_complete(skb))
> goto csum_err;
>
Not true.
The skb->len can be modified by the call to sk_filter() done
by tcp_v4_rcv().
^ permalink raw reply
* Re: [PATCH v3 2/7] net: remove old tcp_optlen function
From: David Miller @ 2010-02-17 23:43 UTC (permalink / raw)
To: william.allen.simpson; +Cc: linux-kernel, netdev, akpm, mchan
In-Reply-To: <4B7793A7.1010500@gmail.com>
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Sun, 14 Feb 2010 01:09:43 -0500
> diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
> index 65df1de..45452c5 100644
> --- a/drivers/net/bnx2.c
> +++ b/drivers/net/bnx2.c
> @@ -6352,6 +6352,8 @@ bnx2_vlan_rx_register(struct net_device *dev, struct vlan_group *vlgrp)
> /* Called with netif_tx_lock.
> * bnx2_tx_int() runs without netif_tx_lock unless it needs to call
> * netif_wake_queue().
> + *
> + * No TCP or IP length checking, per David Miller (see commit log).
> */
This is not appropriate, please do not do this.
We do not refer to commit log messages from the source code. Many
people have the sources via some other means (tarball, distribution
source package, etc.) and won't have any idea where to get this
information.
Also, you don't need to single me out personally. This is an
implication of the structure of the code that I've merely explained to
you, it's not some rule I've personally decided upon.
Thanks.
^ permalink raw reply
* Re: regression due to "flush SAD/SPD generate false events"
From: David Miller @ 2010-02-17 23:40 UTC (permalink / raw)
To: hadi; +Cc: adobriyan, netdev
In-Reply-To: <1266449678.17794.160.camel@bigi>
From: jamal <hadi@cyberus.ca>
Date: Wed, 17 Feb 2010 18:34:38 -0500
> On Wed, 2010-02-17 at 13:42 -0800, David Miller wrote:
>
>> Jamal, if you can find a way to do this without breaking
>> existing applications feel free to send a new version of
>> these patches.
>
> I sent incremental patch. If you still want me to resend
> the whole thing i could after Alexey responds.
Please do, your changes are reverted so I need the whole
thing back.
^ permalink raw reply
* Re: regression due to "flush SAD/SPD generate false events"
From: jamal @ 2010-02-17 23:34 UTC (permalink / raw)
To: David Miller; +Cc: adobriyan, netdev
In-Reply-To: <20100217.134217.244120118.davem@davemloft.net>
On Wed, 2010-02-17 at 13:42 -0800, David Miller wrote:
> Jamal, if you can find a way to do this without breaking
> existing applications feel free to send a new version of
> these patches.
I sent incremental patch. If you still want me to resend
the whole thing i could after Alexey responds.
cheers,
jamal
^ permalink raw reply
* Re: regression due to "flush SAD/SPD generate false events"
From: jamal @ 2010-02-17 23:32 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: davem, netdev
In-Reply-To: <1266448038.17794.135.camel@bigi>
[-- Attachment #1: Type: text/plain, Size: 673 bytes --]
On Wed, 2010-02-17 at 18:07 -0500, jamal wrote:
> When you flush
> an empty table, the time goes up from about 1.5s
> to 3 secs with pfkey. You also see the EAGAIN for
> each flush ...
> I am going to dig a little more ..
Here is a fix. The speed is restored (actually looks a little better
now) - the only thing is if you try to flush an empty table we return
-ESRCH; this seems reasonable, no? So a script like following
---
#!/usr/sbin/setkey -f
flush;
spdflush;
----
will get:
---
bigismall:~# time setkey -f ./setkey-sample
The result of line 2: No such process.
The result of line 3: No such process.
real 0m0.663s
user 0m0.080s
sys 0m0.128s
----
cheers,
jamal
[-- Attachment #2: incr-flush-pfkey --]
[-- Type: text/x-patch, Size: 759 bytes --]
diff --git a/net/key/af_key.c b/net/key/af_key.c
index 8b8e26a..79d2c0f 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -1751,7 +1751,7 @@ static int pfkey_flush(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hd
audit_info.secid = 0;
err = xfrm_state_flush(net, proto, &audit_info);
if (err)
- return 0;
+ return err;
c.data.proto = proto;
c.seq = hdr->sadb_msg_seq;
c.pid = hdr->sadb_msg_pid;
@@ -2713,7 +2713,7 @@ static int pfkey_spdflush(struct sock *sk, struct sk_buff *skb, struct sadb_msg
audit_info.secid = 0;
err = xfrm_policy_flush(net, XFRM_POLICY_TYPE_MAIN, &audit_info);
if (err)
- return 0;
+ return err;
c.data.type = XFRM_POLICY_TYPE_MAIN;
c.event = XFRM_MSG_FLUSHPOLICY;
c.pid = hdr->sadb_msg_pid;
^ permalink raw reply related
* Re: regression due to "flush SAD/SPD generate false events"
From: jamal @ 2010-02-17 23:07 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: davem, netdev
In-Reply-To: <1266442972.17794.51.camel@bigi>
On Wed, 2010-02-17 at 16:42 -0500, jamal wrote:
> I will try to reproduce it in about an hour. Do you have
> anything like selinux being used etc?
I have reproduced it - thanks Alexey. When you flush
an empty table, the time goes up from about 1.5s
to 3 secs with pfkey. You also see the EAGAIN for
each flush ...
I am going to dig a little more ..
cheers,
jamal
^ permalink raw reply
* Re: ixgbe_clean_tx_irq: tx hang 1 detected, resetting adapter (2.6.32.8)
From: Jesse Brandeburg @ 2010-02-17 22:53 UTC (permalink / raw)
To: Jesper Krogh; +Cc: linux-nfs, netdev, Jesse Brandeburg
In-Reply-To: <4B7824F1.6000202@krogh.cc>
On Sun, Feb 14, 2010 at 8:29 AM, Jesper Krogh <jesper@krogh.cc> wrote:
> Hi List.
>
> I have tried to get a dual bond of 2 x 10G NICs using the
> Intel Corporation 82598EB 10-Gigabit AT2 Server Adapter (rev 01)
> going. As first it looked like it "just worked" but when tried to fill
> the links with data one of the NIC's (eth7) hang and did a reset of
> itself, so all data was pushed through the other NIC in the bond (eth8)
>
> Full dmesg below, but I think the important part is this:
>
> [ 2162.745354] ixgbe: eth7: ixgbe_check_tx_hang: Detected Tx Unit Hang
> [ 2162.745356] Tx Queue <4>
> [ 2162.745356] TDH, TDT <e1>, <cc>
> [ 2162.745357] next_to_use <cc>
> [ 2162.745358] next_to_clean <e1>
> [ 2162.745359] tx_buffer_info[next_to_clean]
> [ 2162.745359] time_stamp <1000713d3>
> [ 2162.745360] jiffies <10007152e>
> [ 2163.162478] ixgbe: eth7: ixgbe_clean_tx_irq: tx hang 1 detected,
> resetting adapter
> [ 2163.357333] bonding: bond0: link status definitely down for interface
> eth7, disabling it
> [ 2168.670342] ixgbe: eth7 NIC Link is Up 10 Gbps, Flow Control: None
Hi Jesper, my first thought was flow control, but I can see you have it off.
Can we get some more details on the hardware and bios version? What
about some dmidecode output. I'm checking here if we have any
hardware like this.
are you running ubuntu 9.10 or something else?
Wow, thats a monster machine, 8 nodes, 128GB ram. Can we get a full
lspci -vvv output, as well as ethtool -e eth7 and eth8
32 has ixgbe with a known issue of multiple mappings on transmit
possibly causing some problems, could it be that you're running into
this? can you apply commit e5a43549f7a58509a91b299a51337d386697b92c
and see if it fixes your issue?
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/3] vlan: adds vlan_dev_select_queue
From: Vasu Dev @ 2010-02-17 22:40 UTC (permalink / raw)
To: David Miller, eric.dumazet; +Cc: jeffrey.t.kirsher, netdev, gospo, vasu.dev
In-Reply-To: <20100217.134330.48386140.davem@davemloft.net>
On Wed, 2010-02-17 at 13:43 -0800, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 17 Feb 2010 14:51:15 +0100
>
> > This is a bit dangerous and deserves a self contained patch IMHO.
> >
OK, I'll create separate patch for this.
> > I would add for example a
> > BUG_ON(vlandev->real_num_tx_queues > vlandev->num_tx_queues)
> >
I'll add this.
> > ------------------
> >
> > For performance reason, we could avoid calling vlan_dev_select_queue()
> > for real devices without ndo_select_queue() handler, this would need to
> > mirror vlan_netdev_ops & vlan_netdev_accel_ops.
> >
This means vlan_netdev_ops & vlan_netdev_accel_ops not to be const
anymore so that vlan_dev_select_queue() could be initialized to vlan ops
based on real dev ndo_select_queue() present or not, should be okay to
be not const anymore. I'll update patch as suggested.
> > It would also make vlan_dev_select_queue shorter and not duplicates
> > internals of net/dev/core.c :
> >
Good reasons.
> > static u16 vlan_dev_select_queue(struct net_device *dev, struct sk_buff
> > *skb)
> > {
> > struct net_device *rdev = vlan_dev_info(dev)->real_dev;
> > const struct net_device_ops *ops = rdev->netdev_ops;
> >
> > return ops->ndo_select_queue(rdev, skb);
> > }
> >
> >
>
> Jeff, please resubmit this patch set after addressing
> Eric's feedback.
>
I'm updating patches per Eric's feedback to have Jeff resubmit these
patches.
Vasu
^ permalink raw reply
* [net-next-2.6 PATCH] cxgb3: convert to use netdev_for_each_addr
From: Jiri Pirko @ 2010-02-17 22:27 UTC (permalink / raw)
To: netdev; +Cc: davem, divy
Removed whole t3_rx_mode structure and appropriate helpers cause they are no
longer needed.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
drivers/net/cxgb3/common.h | 28 +---------------------------
drivers/net/cxgb3/cxgb3_main.c | 8 ++------
drivers/net/cxgb3/xgmac.c | 15 ++++++++-------
3 files changed, 11 insertions(+), 40 deletions(-)
diff --git a/drivers/net/cxgb3/common.h b/drivers/net/cxgb3/common.h
index 6ff356d..fe08a00 100644
--- a/drivers/net/cxgb3/common.h
+++ b/drivers/net/cxgb3/common.h
@@ -67,32 +67,6 @@
/* Additional NETIF_MSG_* categories */
#define NETIF_MSG_MMIO 0x8000000
-struct t3_rx_mode {
- struct net_device *dev;
- struct dev_mc_list *mclist;
- unsigned int idx;
-};
-
-static inline void init_rx_mode(struct t3_rx_mode *p, struct net_device *dev,
- struct dev_mc_list *mclist)
-{
- p->dev = dev;
- p->mclist = mclist;
- p->idx = 0;
-}
-
-static inline u8 *t3_get_next_mcaddr(struct t3_rx_mode *rm)
-{
- u8 *addr = NULL;
-
- if (rm->mclist && rm->idx < rm->dev->mc_count) {
- addr = rm->mclist->dmi_addr;
- rm->mclist = rm->mclist->next;
- rm->idx++;
- }
- return addr;
-}
-
enum {
MAX_NPORTS = 2, /* max # of ports */
MAX_FRAME_SIZE = 10240, /* max MAC frame size, including header + FCS */
@@ -746,7 +720,7 @@ void t3_mac_enable_exact_filters(struct cmac *mac);
int t3_mac_enable(struct cmac *mac, int which);
int t3_mac_disable(struct cmac *mac, int which);
int t3_mac_set_mtu(struct cmac *mac, unsigned int mtu);
-int t3_mac_set_rx_mode(struct cmac *mac, struct t3_rx_mode *rm);
+int t3_mac_set_rx_mode(struct cmac *mac, struct net_device *dev);
int t3_mac_set_address(struct cmac *mac, unsigned int idx, u8 addr[6]);
int t3_mac_set_num_ucast(struct cmac *mac, int n);
const struct mac_stats *t3_mac_update_stats(struct cmac *mac);
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index 73622f5..6fd968a 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -324,11 +324,9 @@ void t3_os_phymod_changed(struct adapter *adap, int port_id)
static void cxgb_set_rxmode(struct net_device *dev)
{
- struct t3_rx_mode rm;
struct port_info *pi = netdev_priv(dev);
- init_rx_mode(&rm, dev, dev->mc_list);
- t3_mac_set_rx_mode(&pi->mac, &rm);
+ t3_mac_set_rx_mode(&pi->mac, dev);
}
/**
@@ -339,17 +337,15 @@ static void cxgb_set_rxmode(struct net_device *dev)
*/
static void link_start(struct net_device *dev)
{
- struct t3_rx_mode rm;
struct port_info *pi = netdev_priv(dev);
struct cmac *mac = &pi->mac;
- init_rx_mode(&rm, dev, dev->mc_list);
t3_mac_reset(mac);
t3_mac_set_num_ucast(mac, MAX_MAC_IDX);
t3_mac_set_mtu(mac, dev->mtu);
t3_mac_set_address(mac, LAN_MAC_IDX, dev->dev_addr);
t3_mac_set_address(mac, SAN_MAC_IDX, pi->iscsic.mac_addr);
- t3_mac_set_rx_mode(mac, &rm);
+ t3_mac_set_rx_mode(mac, dev);
t3_link_start(&pi->phy, mac, &pi->link_config);
t3_mac_enable(mac, MAC_DIRECTION_RX | MAC_DIRECTION_TX);
}
diff --git a/drivers/net/cxgb3/xgmac.c b/drivers/net/cxgb3/xgmac.c
index 0c08de5..c142a21 100644
--- a/drivers/net/cxgb3/xgmac.c
+++ b/drivers/net/cxgb3/xgmac.c
@@ -297,29 +297,30 @@ static int hash_hw_addr(const u8 * addr)
return hash;
}
-int t3_mac_set_rx_mode(struct cmac *mac, struct t3_rx_mode *rm)
+int t3_mac_set_rx_mode(struct cmac *mac, struct net_device *dev)
{
u32 val, hash_lo, hash_hi;
struct adapter *adap = mac->adapter;
unsigned int oft = mac->offset;
val = t3_read_reg(adap, A_XGM_RX_CFG + oft) & ~F_COPYALLFRAMES;
- if (rm->dev->flags & IFF_PROMISC)
+ if (dev->flags & IFF_PROMISC)
val |= F_COPYALLFRAMES;
t3_write_reg(adap, A_XGM_RX_CFG + oft, val);
- if (rm->dev->flags & IFF_ALLMULTI)
+ if (dev->flags & IFF_ALLMULTI)
hash_lo = hash_hi = 0xffffffff;
else {
- u8 *addr;
+ struct dev_mc_list *dmi;
int exact_addr_idx = mac->nucast;
hash_lo = hash_hi = 0;
- while ((addr = t3_get_next_mcaddr(rm)))
+ netdev_for_each_mc_addr(dmi, dev)
if (exact_addr_idx < EXACT_ADDR_FILTERS)
- set_addr_filter(mac, exact_addr_idx++, addr);
+ set_addr_filter(mac, exact_addr_idx++,
+ dmi->dmi_addr);
else {
- int hash = hash_hw_addr(addr);
+ int hash = hash_hw_addr(dmi->dmi_addr);
if (hash < 32)
hash_lo |= (1 << hash);
--
1.6.6
^ permalink raw reply related
* [net-next-2.6 PATCH v3 3/3] fs_enet: add FEC TX buffer alignment workaround for MPC5121
From: Anatolij Gustschin @ 2010-02-17 22:08 UTC (permalink / raw)
To: netdev
Cc: linuxppc-dev, David S. Miller, Grant Likely, Detlev Zundel,
Wolfgang Denk, John Rigby, Anatolij Gustschin, Piotr Ziecik
In-Reply-To: <1266418530-2727-4-git-send-email-agust@denx.de>
MPC5121 FEC requeries 4-byte alignmnent for TX data buffers.
This patch is a work around that copies misaligned tx packets
to an aligned skb before sending.
Signed-off-by: John Rigby <jcrigby@gmail.com>
Signed-off-by: Piotr Ziecik <kosmo@semihalf.com>
Signed-off-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
Changes since v2:
- ratelimit warning message
- use skb->len + 4 as size for allocation of the new skb
with aligned buffer.
drivers/net/fs_enet/fs_enet-main.c | 47 ++++++++++++++++++++++++++++++++++++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index 4297021..0770e2f 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -580,6 +580,40 @@ void fs_cleanup_bds(struct net_device *dev)
/**********************************************************************************/
+#ifdef CONFIG_FS_ENET_MPC5121_FEC
+/*
+ * MPC5121 FEC requeries 4-byte alignment for TX data buffer!
+ */
+static struct sk_buff *tx_skb_align_workaround(struct net_device *dev,
+ struct sk_buff *skb)
+{
+ struct sk_buff *new_skb;
+ struct fs_enet_private *fep = netdev_priv(dev);
+
+ /* Alloc new skb */
+ new_skb = dev_alloc_skb(skb->len + 4);
+ if (!new_skb) {
+ if (net_ratelimit()) {
+ dev_warn(fep->dev,
+ "Memory squeeze, dropping tx packet.\n");
+ }
+ return NULL;
+ }
+
+ /* Make sure new skb is properly aligned */
+ skb_align(new_skb, 4);
+
+ /* Copy data to new skb ... */
+ skb_copy_from_linear_data(skb, new_skb->data, skb->len);
+ skb_put(new_skb, skb->len);
+
+ /* ... and free an old one */
+ dev_kfree_skb_any(skb);
+
+ return new_skb;
+}
+#endif
+
static int fs_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
@@ -588,6 +622,19 @@ static int fs_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
u16 sc;
unsigned long flags;
+#ifdef CONFIG_FS_ENET_MPC5121_FEC
+ if (((unsigned long)skb->data) & 0x3) {
+ skb = tx_skb_align_workaround(dev, skb);
+ if (!skb) {
+ /*
+ * We have lost packet due to memory allocation error
+ * in tx_skb_align_workaround(). Hopefully original
+ * skb is still valid, so try transmit it later.
+ */
+ return NETDEV_TX_BUSY;
+ }
+ }
+#endif
spin_lock_irqsave(&fep->tx_lock, flags);
/*
--
1.6.3.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox