* [PATCH] bonding-tlb: better balance when choosing slaves
From: Weiping Pan(潘卫平) @ 2011-04-02 14:09 UTC (permalink / raw)
Cc: Weiping Pan , Jay Vosburgh, Andy Gospodarek,
open list:BONDING DRIVER, open list
tlb_get_least_loaded_slave() always chooses slave from
bonding->first_slave, that gives the beginnig slaves more chances to be used.
Let tlb_get_least_loaded_slave() chooses slave from a random positon in the
slave list, make all slaves transmit packets more balanced.
Signed-off-by: Weiping Pan(潘卫平) <panweiping3@gmail.com>
---
drivers/net/bonding/bond_alb.c | 17 +++++++++++++++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index 9bc5de3..9fa64b0 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@ -36,6 +36,7 @@
#include <linux/if_bonding.h>
#include <linux/if_vlan.h>
#include <linux/in.h>
+#include <linux/random.h>
#include <net/ipx.h>
#include <net/arp.h>
#include <net/ipv6.h>
@@ -206,15 +207,27 @@ static long long compute_gap(struct slave *slave)
/* Caller must hold bond lock for read */
static struct slave *tlb_get_least_loaded_slave(struct bonding *bond)
{
- struct slave *slave, *least_loaded;
+ struct slave *slave, *least_loaded, *start_slave;
long long max_gap;
int i;
+ u8 n;
least_loaded = NULL;
+ start_slave = bond->first_slave;
max_gap = LLONG_MIN;
+
+ get_random_bytes(&n, 1);
+
+ if (bond->slave_cnt == 0)
+ return NULL;
+ n = n % bond->slave_cnt;
+
+ for (i=0; i<n; ++i) {
+ start_slave = start_slave->next;
+ }
/* Find the slave with the largest gap */
- bond_for_each_slave(bond, slave, i) {
+ bond_for_each_slave_from(bond, slave, i, start_slave) {
if (SLAVE_IS_OK(slave)) {
long long gap = compute_gap(slave);
--
1.7.4
^ permalink raw reply related
* INVESTMENT INITIATIVE!!
From: JOZEF RUUD ROOSEVELT @ 2011-04-02 13:18 UTC (permalink / raw)
Attention Please,
I am Jozef Ruud Roosevelt, I have a proposition Involving an investment
initiative in your country economy to discuss with you, It will be of
mutual benefit to both of us, and I believe we can handle it together,
once we have a common understanding and mutual cooperation in the
execution of the modalities. I work with Abn Amro N.V.
Should you be interested, please email back to me through this email
address: (jozef_rosevelt@live.com).
I await your earliest response.
Yours Sincerely,
JOZEF RUUD ROOSEVELT.
^ permalink raw reply
* Re: extending feature word.
From: Michał Mirosław @ 2011-04-02 12:42 UTC (permalink / raw)
To: Mahesh Bandewar; +Cc: linux-netdev, Ben Hutchings, David Miller
In-Reply-To: <BANLkTin52LqjxtVT+_y+gGam-QxeLq_iOA@mail.gmail.com>
On Fri, Apr 01, 2011 at 07:07:05PM -0700, Mahesh Bandewar wrote:
> Thanks for your comments on my loop-back patch. I was looking at the
> code today from the perspective of extending various "features" for
> word to an array of words and as Michael has pointed out, it's a huge
> change. So I'm thinking on the following lines
> (include/linux/netdevice.h)
>
> +#define DEV_FEATURE_WORDS 2
> +#define LEGACY_FEATURE_WORD 0
> /* currently active device features */
> - u32 features;
> + u32 features[DEV_FEATURE_WORDS];
> /* user-changeable features */
> - u32 hw_features;
> + u32 hw_features[DEV_FEATURE_WORDS];
> /* user-requested features */
> - u32 wanted_features;
> + u32 wanted_features[DEV_FEATURE_WORDS];
> /* VLAN feature mask */
> - u32 vlan_features;
> + u32 vlan_features[DEV_FEATURE_WORDS];
> +#define legacy_features features[LEGACY_FEATURE_WORD]
> +#define legacy_hw_features hw_features[LEGACY_FEATURE_WORD]
> +#define legacy_wanted_features wanted_features[LEGACY_FEATURE_WORD]
> +#define legacy_vlan_features vlan_features[LEGACY_FEATURE_WORD]
>
>
> So that it will be a matter of -
>
> s/features/legacy_features/
> s/hw_features/legacy_hw_features/
> s/wanted_features/legacy_wanted_features/
> s/vlan_features/legacy_vlan_features/
>
> to start with as a first step. Once this is done, legacy_* can be
> changed with respective arrays and modified as per the need. Comments?
You could just s/features/features[0]/ as well. Why the extra hiding?
If you want to split the work, it would be clearer to first convert
hw_features and wanted_features (with all the core code touching it -
this is the easy part), then vlan_features (this includes drivers'
and VLAN code) and then features (it's all over).
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [RFC PATCH] vlan: convert VLAN devices to use hw_features
From: Michał Mirosław @ 2011-04-02 12:28 UTC (permalink / raw)
To: Jesse Gross
Cc: netdev, Patrick McHardy, David S. Miller, John Fastabend,
Eric Dumazet
In-Reply-To: <AANLkTim68LoiyFA4+3weHkmuVpc=xxmHnheiEf_OH0LK@mail.gmail.com>
On Fri, Apr 01, 2011 at 06:55:04PM -0700, Jesse Gross wrote:
> 2011/3/31 Michał Mirosław <mirq-linux@rere.qmqm.pl>:
> > diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
> > index e34ea9e..b84a46b 100644
> > --- a/net/8021q/vlan_dev.c
> > +++ b/net/8021q/vlan_dev.c
> > @@ -704,8 +704,8 @@ static int vlan_dev_init(struct net_device *dev)
> > (1<<__LINK_STATE_DORMANT))) |
> > (1<<__LINK_STATE_PRESENT);
> >
> > - dev->features |= real_dev->features & real_dev->vlan_features;
> > - dev->features |= NETIF_F_LLTX;
> > + dev->hw_features = real_dev->vlan_features & NETIF_F_ALL_TX_OFFLOADS;
> > + dev->features |= real_dev->vlan_features | NETIF_F_LLTX;
> Shouldn't this continue to use real_dev->feaures &
> real_dev->vlan_features? In some places capabilities are blindly
> added to vlan_features on the assumption that they will later be ANDed
> with the real capabilities of the hardware (for example, see
> register_netdevice()).
real_dev->features are ANDed on every netdev_update_features() (also called
by register_netdevice()) by vlan_dev_fix_features(). This sets all
vlan_features as wanted to be enabled, so that if some are initially disabled
on the base device and later enabled then they can be propagated back to vlan
devices. The other way would be to set wanted_features based on current
real_dev->features & real_dev->vlan_features.
Hmm. I just noticed that I missed vlan_transfer_features() in the conversion.
I'll fix that.
Best Regards,
Michał Mirosław
^ permalink raw reply
* [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Jiri Pirko @ 2011-04-02 10:26 UTC (permalink / raw)
To: netdev
Cc: davem, shemminger, kaber, fubar, eric.dumazet, nicolas.2p.debian,
andy, xiaosuo, jesse
Now there are 2 paths for rx vlan frames. When rx-vlan-hw-accel is
enabled, skb is untagged by NIC, vlan_tci is set and the skb gets into
vlan code in __netif_receive_skb - vlan_hwaccel_do_receive.
For non-rx-vlan-hw-accel however, tagged skb goes thru whole
__netif_receive_skb, it's untagged in ptype_base hander and reinjected
This incosistency is fixed by this patch. Vlan untagging happens early in
__netif_receive_skb so the rest of code (ptype_all handlers, rx_handlers)
see the skb like it was untagged by hw.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
include/linux/if_vlan.h | 10 ++-
net/8021q/vlan.c | 8 --
net/8021q/vlan.h | 2 -
net/8021q/vlan_core.c | 86 +++++++++++++++++++++++-
net/8021q/vlan_dev.c | 173 -----------------------------------------------
net/core/dev.c | 8 ++-
6 files changed, 100 insertions(+), 187 deletions(-)
diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
index 635e1fa..998b299 100644
--- a/include/linux/if_vlan.h
+++ b/include/linux/if_vlan.h
@@ -132,7 +132,8 @@ extern u16 vlan_dev_vlan_id(const struct net_device *dev);
extern int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp,
u16 vlan_tci, int polling);
-extern bool vlan_hwaccel_do_receive(struct sk_buff **skb);
+extern bool vlan_do_receive(struct sk_buff **skb);
+extern struct sk_buff *vlan_untag(struct sk_buff *skb);
extern gro_result_t
vlan_gro_receive(struct napi_struct *napi, struct vlan_group *grp,
unsigned int vlan_tci, struct sk_buff *skb);
@@ -166,13 +167,18 @@ static inline int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp,
return NET_XMIT_SUCCESS;
}
-static inline bool vlan_hwaccel_do_receive(struct sk_buff **skb)
+static inline bool vlan_do_receive(struct sk_buff **skb)
{
if ((*skb)->vlan_tci & VLAN_VID_MASK)
(*skb)->pkt_type = PACKET_OTHERHOST;
return false;
}
+inline struct sk_buff *vlan_untag(struct sk_buff *skb)
+{
+ return skb;
+}
+
static inline gro_result_t
vlan_gro_receive(struct napi_struct *napi, struct vlan_group *grp,
unsigned int vlan_tci, struct sk_buff *skb)
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index 7850412..59f0a9d 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -49,11 +49,6 @@ const char vlan_version[] = DRV_VERSION;
static const char vlan_copyright[] = "Ben Greear <greearb@candelatech.com>";
static const char vlan_buggyright[] = "David S. Miller <davem@redhat.com>";
-static struct packet_type vlan_packet_type __read_mostly = {
- .type = cpu_to_be16(ETH_P_8021Q),
- .func = vlan_skb_recv, /* VLAN receive method */
-};
-
/* End of global variables definitions. */
static void vlan_group_free(struct vlan_group *grp)
@@ -688,7 +683,6 @@ static int __init vlan_proto_init(void)
if (err < 0)
goto err4;
- dev_add_pack(&vlan_packet_type);
vlan_ioctl_set(vlan_ioctl_handler);
return 0;
@@ -709,8 +703,6 @@ static void __exit vlan_cleanup_module(void)
unregister_netdevice_notifier(&vlan_notifier_block);
- dev_remove_pack(&vlan_packet_type);
-
unregister_pernet_subsys(&vlan_net_ops);
rcu_barrier(); /* Wait for completion of call_rcu()'s */
diff --git a/net/8021q/vlan.h b/net/8021q/vlan.h
index 5687c9b..c3408de 100644
--- a/net/8021q/vlan.h
+++ b/net/8021q/vlan.h
@@ -75,8 +75,6 @@ static inline struct vlan_dev_info *vlan_dev_info(const struct net_device *dev)
}
/* found in vlan_dev.c */
-int vlan_skb_recv(struct sk_buff *skb, struct net_device *dev,
- struct packet_type *ptype, struct net_device *orig_dev);
void vlan_dev_set_ingress_priority(const struct net_device *dev,
u32 skb_prio, u16 vlan_prio);
int vlan_dev_set_egress_priority(const struct net_device *dev,
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index ce8e3ab..bc83ecc 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -4,7 +4,7 @@
#include <linux/netpoll.h>
#include "vlan.h"
-bool vlan_hwaccel_do_receive(struct sk_buff **skbp)
+bool vlan_do_receive(struct sk_buff **skbp)
{
struct sk_buff *skb = *skbp;
u16 vlan_id = skb->vlan_tci & VLAN_VID_MASK;
@@ -88,3 +88,87 @@ gro_result_t vlan_gro_frags(struct napi_struct *napi, struct vlan_group *grp,
return napi_gro_frags(napi);
}
EXPORT_SYMBOL(vlan_gro_frags);
+
+static inline struct sk_buff *vlan_check_reorder_header(struct sk_buff *skb)
+{
+ if (vlan_dev_info(skb->dev)->flags & VLAN_FLAG_REORDER_HDR) {
+ if (skb_cow(skb, skb_headroom(skb)) < 0)
+ skb = NULL;
+ if (skb) {
+ /* Lifted from Gleb's VLAN code... */
+ memmove(skb->data - ETH_HLEN,
+ skb->data - VLAN_ETH_HLEN, 12);
+ skb->mac_header += VLAN_HLEN;
+ }
+ }
+ return skb;
+}
+
+static inline void vlan_set_encap_proto(struct sk_buff *skb,
+ struct vlan_hdr *vhdr)
+{
+ __be16 proto;
+ unsigned char *rawp;
+
+ /*
+ * Was a VLAN packet, grab the encapsulated protocol, which the layer
+ * three protocols care about.
+ */
+
+ proto = vhdr->h_vlan_encapsulated_proto;
+ if (ntohs(proto) >= 1536) {
+ skb->protocol = proto;
+ return;
+ }
+
+ rawp = skb->data;
+ if (*(unsigned short *) rawp == 0xFFFF)
+ /*
+ * This is a magic hack to spot IPX packets. Older Novell
+ * breaks the protocol design and runs IPX over 802.3 without
+ * an 802.2 LLC layer. We look for FFFF which isn't a used
+ * 802.2 SSAP/DSAP. This won't work for fault tolerant netware
+ * but does for the rest.
+ */
+ skb->protocol = htons(ETH_P_802_3);
+ else
+ /*
+ * Real 802.2 LLC
+ */
+ skb->protocol = htons(ETH_P_802_2);
+}
+
+struct sk_buff *vlan_untag(struct sk_buff *skb)
+{
+ struct vlan_hdr *vhdr;
+ u16 vlan_tci;
+
+ if (unlikely(vlan_tx_tag_present(skb))) {
+ /* vlan_tci is already set-up so leave this for another time */
+ return skb;
+ }
+
+ skb = skb_share_check(skb, GFP_ATOMIC);
+ if (unlikely(!skb))
+ goto err_free;
+
+ if (unlikely(!pskb_may_pull(skb, VLAN_HLEN)))
+ goto err_free;
+
+ vhdr = (struct vlan_hdr *) skb->data;
+ vlan_tci = ntohs(vhdr->h_vlan_TCI);
+ __vlan_hwaccel_put_tag(skb, vlan_tci);
+
+ skb_pull_rcsum(skb, VLAN_HLEN);
+ vlan_set_encap_proto(skb, vhdr);
+
+ skb = vlan_check_reorder_header(skb);
+ if (unlikely(!skb))
+ goto err_free;
+
+ return skb;
+
+err_free:
+ kfree_skb(skb);
+ return NULL;
+}
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index e34ea9e..b4f061f 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -65,179 +65,6 @@ static int vlan_dev_rebuild_header(struct sk_buff *skb)
return 0;
}
-static inline struct sk_buff *vlan_check_reorder_header(struct sk_buff *skb)
-{
- if (vlan_dev_info(skb->dev)->flags & VLAN_FLAG_REORDER_HDR) {
- if (skb_cow(skb, skb_headroom(skb)) < 0)
- skb = NULL;
- if (skb) {
- /* Lifted from Gleb's VLAN code... */
- memmove(skb->data - ETH_HLEN,
- skb->data - VLAN_ETH_HLEN, 12);
- skb->mac_header += VLAN_HLEN;
- }
- }
-
- return skb;
-}
-
-static inline void vlan_set_encap_proto(struct sk_buff *skb,
- struct vlan_hdr *vhdr)
-{
- __be16 proto;
- unsigned char *rawp;
-
- /*
- * Was a VLAN packet, grab the encapsulated protocol, which the layer
- * three protocols care about.
- */
-
- proto = vhdr->h_vlan_encapsulated_proto;
- if (ntohs(proto) >= 1536) {
- skb->protocol = proto;
- return;
- }
-
- rawp = skb->data;
- if (*(unsigned short *)rawp == 0xFFFF)
- /*
- * This is a magic hack to spot IPX packets. Older Novell
- * breaks the protocol design and runs IPX over 802.3 without
- * an 802.2 LLC layer. We look for FFFF which isn't a used
- * 802.2 SSAP/DSAP. This won't work for fault tolerant netware
- * but does for the rest.
- */
- skb->protocol = htons(ETH_P_802_3);
- else
- /*
- * Real 802.2 LLC
- */
- skb->protocol = htons(ETH_P_802_2);
-}
-
-/*
- * Determine the packet's protocol ID. The rule here is that we
- * assume 802.3 if the type field is short enough to be a length.
- * This is normal practice and works for any 'now in use' protocol.
- *
- * Also, at this point we assume that we ARE dealing exclusively with
- * VLAN packets, or packets that should be made into VLAN packets based
- * on a default VLAN ID.
- *
- * NOTE: Should be similar to ethernet/eth.c.
- *
- * SANITY NOTE: This method is called when a packet is moving up the stack
- * towards userland. To get here, it would have already passed
- * through the ethernet/eth.c eth_type_trans() method.
- * SANITY NOTE 2: We are referencing to the VLAN_HDR frields, which MAY be
- * stored UNALIGNED in the memory. RISC systems don't like
- * such cases very much...
- * SANITY NOTE 2a: According to Dave Miller & Alexey, it will always be
- * aligned, so there doesn't need to be any of the unaligned
- * stuff. It has been commented out now... --Ben
- *
- */
-int vlan_skb_recv(struct sk_buff *skb, struct net_device *dev,
- struct packet_type *ptype, struct net_device *orig_dev)
-{
- struct vlan_hdr *vhdr;
- struct vlan_pcpu_stats *rx_stats;
- struct net_device *vlan_dev;
- u16 vlan_id;
- u16 vlan_tci;
-
- skb = skb_share_check(skb, GFP_ATOMIC);
- if (skb == NULL)
- goto err_free;
-
- if (unlikely(!pskb_may_pull(skb, VLAN_HLEN)))
- goto err_free;
-
- vhdr = (struct vlan_hdr *)skb->data;
- vlan_tci = ntohs(vhdr->h_vlan_TCI);
- vlan_id = vlan_tci & VLAN_VID_MASK;
-
- rcu_read_lock();
- vlan_dev = vlan_find_dev(dev, vlan_id);
-
- /* If the VLAN device is defined, we use it.
- * If not, and the VID is 0, it is a 802.1p packet (not
- * really a VLAN), so we will just netif_rx it later to the
- * original interface, but with the skb->proto set to the
- * wrapped proto: we do nothing here.
- */
-
- if (!vlan_dev) {
- if (vlan_id) {
- pr_debug("%s: ERROR: No net_device for VID: %u on dev: %s\n",
- __func__, vlan_id, dev->name);
- goto err_unlock;
- }
- rx_stats = NULL;
- } else {
- skb->dev = vlan_dev;
-
- rx_stats = this_cpu_ptr(vlan_dev_info(skb->dev)->vlan_pcpu_stats);
-
- u64_stats_update_begin(&rx_stats->syncp);
- rx_stats->rx_packets++;
- rx_stats->rx_bytes += skb->len;
-
- skb->priority = vlan_get_ingress_priority(skb->dev, vlan_tci);
-
- pr_debug("%s: priority: %u for TCI: %hu\n",
- __func__, skb->priority, vlan_tci);
-
- switch (skb->pkt_type) {
- case PACKET_BROADCAST:
- /* Yeah, stats collect these together.. */
- /* stats->broadcast ++; // no such counter :-( */
- break;
-
- case PACKET_MULTICAST:
- rx_stats->rx_multicast++;
- break;
-
- case PACKET_OTHERHOST:
- /* Our lower layer thinks this is not local, let's make
- * sure.
- * This allows the VLAN to have a different MAC than the
- * underlying device, and still route correctly.
- */
- if (!compare_ether_addr(eth_hdr(skb)->h_dest,
- skb->dev->dev_addr))
- skb->pkt_type = PACKET_HOST;
- break;
- default:
- break;
- }
- u64_stats_update_end(&rx_stats->syncp);
- }
-
- skb_pull_rcsum(skb, VLAN_HLEN);
- vlan_set_encap_proto(skb, vhdr);
-
- if (vlan_dev) {
- skb = vlan_check_reorder_header(skb);
- if (!skb) {
- rx_stats->rx_errors++;
- goto err_unlock;
- }
- }
-
- netif_rx(skb);
-
- rcu_read_unlock();
- return NET_RX_SUCCESS;
-
-err_unlock:
- rcu_read_unlock();
-err_free:
- atomic_long_inc(&dev->rx_dropped);
- kfree_skb(skb);
- return NET_RX_DROP;
-}
-
static inline u16
vlan_dev_get_egress_qos_mask(struct net_device *dev, struct sk_buff *skb)
{
diff --git a/net/core/dev.c b/net/core/dev.c
index 3da9fb0..bfe9fce 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3130,6 +3130,12 @@ another_round:
__this_cpu_inc(softnet_data.processed);
+ if (skb->protocol == cpu_to_be16(ETH_P_8021Q)) {
+ skb = vlan_untag(skb);
+ if (unlikely(!skb))
+ goto out;
+ }
+
#ifdef CONFIG_NET_CLS_ACT
if (skb->tc_verd & TC_NCLS) {
skb->tc_verd = CLR_TC_NCLS(skb->tc_verd);
@@ -3177,7 +3183,7 @@ ncls:
ret = deliver_skb(skb, pt_prev, orig_dev);
pt_prev = NULL;
}
- if (vlan_hwaccel_do_receive(&skb)) {
+ if (vlan_do_receive(&skb)) {
ret = __netif_receive_skb(skb);
goto out;
} else if (unlikely(!skb))
--
1.7.4
^ permalink raw reply related
* nfs client doesn't work [was: mmotm 2011-03-31-14-48 uploaded]
From: Jiri Slaby @ 2011-04-02 8:56 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
mm-commits-u79uwXL29TY76Z2rM5mHXA, ML netdev,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, Trond Myklebust, Jiri Slaby
In-Reply-To: <201103312224.p2VMOA5g000983-AB4EexQrvXRQetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
On 03/31/2011 11:48 PM, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org wrote:
> The mm-of-the-moment snapshot 2011-03-31-14-48 has been uploaded to
Hi, nfs client is defunct in this kernel. Tcpdump says:
10:51:55.489717 IP 10.20.11.33.759945860 > 10.20.3.2.2049: 132 getattr
fh 0,0/24
10:51:55.515927 IP 10.20.3.2.2049 > 10.20.11.33.759945860: reply ok 44
getattr ERROR: Operation not permitted
10:51:55.515949 IP 10.20.11.33.921 > 10.20.3.2.2049: Flags [.], ack
3569361440, win 115, options [nop,nop,TS val 599750 ecr 255058541], length 0
10:52:04.130310 IP 10.20.11.33.793500292 > 10.20.3.2.2049: 76 getattr fh
0,0/24
10:52:04.152178 IP 10.20.3.2.2049 > 10.20.11.33.793500292: reply ok 44
getattr ERROR: Operation not permitted
If I run the same mount command (mount -oro,intr host:dir mountpoint)
from within a virtual machine with 2.6.38.2 there, everything mounts OK.
thanks,
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 1/1] net/fec: do not pass NULL dev to DMA API
From: Dong Aisheng-B29396 @ 2011-04-02 8:40 UTC (permalink / raw)
To: David Miller, liu.h.jason@gmail.com
Cc: Guo Shawn-R65073, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20110402.013541.02274640.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Saturday, April 02, 2011 4:36 PM
> To: liu.h.jason@gmail.com
> Cc: Guo Shawn-R65073; netdev@vger.kernel.org; Dong Aisheng-B29396; linux-
> arm-kernel@lists.infradead.org
> Subject: Re: [PATCH 1/1] net/fec: do not pass NULL dev to DMA API
>
> From: Jason Liu <liu.h.jason@gmail.com>
> Date: Sat, 2 Apr 2011 16:35:19 +0800
>
> > 2011/4/2 Shawn Guo <shawn.guo@freescale.com>:
> >> Hi David,
> >>
> >> On Sat, Apr 02, 2011 at 12:57:14AM -0700, David Miller wrote:
> >>>
> >>> First, your patches never make it to the mailing list because the
> >>> list server rejects your postings, due to the fact that there are
> >>> syntax errors in your email headers:
> >>>
> >>> Illegal-Object: Syntax error in From: address found on
> vger.kernel.org:
> >>> From: Aisheng.Dong<b29396@freescale.com>
> >>> ^-missing end of mailbox
> >>>
> >> Yes, we were aware of that the mail did not get distributed by vger
> >> list. But we do not know why. Thanks for telling.
> >>
> >> I'm not quite sure about the "^" indication. Is it telling that
> >> there should be a space between display name and mail address?
> >
> > We should not use A.B <>, instead should use A B <>.
>
> Yes, this is also true.
>
> Characters such as "." must not appear in email headers in this context
> unless protected by double quotes.
Thanks a lot David.
This issue has bothered me a lot and finally the root cause is found.
For the patch I just found it was already fixed in your 2.6.x -next tree.
Thanks for the info.
Regards
Aisheng
^ permalink raw reply
* Re: [PATCH 1/1] net/fec: do not pass NULL dev to DMA API
From: David Miller @ 2011-04-02 8:35 UTC (permalink / raw)
To: liu.h.jason; +Cc: shawn.guo, netdev, b29396, linux-arm-kernel
In-Reply-To: <AANLkTi=FMsH7Px2m9WkRVyHfGZ9MLvgp-XPHu3Amsu7+@mail.gmail.com>
From: Jason Liu <liu.h.jason@gmail.com>
Date: Sat, 2 Apr 2011 16:35:19 +0800
> 2011/4/2 Shawn Guo <shawn.guo@freescale.com>:
>> Hi David,
>>
>> On Sat, Apr 02, 2011 at 12:57:14AM -0700, David Miller wrote:
>>>
>>> First, your patches never make it to the mailing list because the list
>>> server rejects your postings, due to the fact that there are syntax
>>> errors in your email headers:
>>>
>>> Illegal-Object: Syntax error in From: address found on vger.kernel.org:
>>> From: Aisheng.Dong<b29396@freescale.com>
>>> ^-missing end of mailbox
>>>
>> Yes, we were aware of that the mail did not get distributed by vger
>> list. But we do not know why. Thanks for telling.
>>
>> I'm not quite sure about the "^" indication. Is it telling that there
>> should be a space between display name and mail address?
>
> We should not use A.B <>, instead should use A B <>.
Yes, this is also true.
Characters such as "." must not appear in email headers in this
context unless protected by double quotes.
^ permalink raw reply
* Re: [PATCH 1/1] net/fec: do not pass NULL dev to DMA API
From: David Miller @ 2011-04-02 8:34 UTC (permalink / raw)
To: shawn.guo; +Cc: b29396, netdev, linux-arm-kernel
In-Reply-To: <20110402083131.GB26533@S2100-06.ap.freescale.net>
From: Shawn Guo <shawn.guo@freescale.com>
Date: Sat, 2 Apr 2011 16:31:32 +0800
> I'm not quite sure about the "^" indication. Is it telling that there
> should be a space between display name and mail address?
Yes.
^ permalink raw reply
* Re: [PATCH 1/1] net/fec: do not pass NULL dev to DMA API
From: Jason Liu @ 2011-04-02 8:35 UTC (permalink / raw)
To: Shawn Guo; +Cc: David Miller, netdev, b29396, linux-arm-kernel
In-Reply-To: <20110402083131.GB26533@S2100-06.ap.freescale.net>
2011/4/2 Shawn Guo <shawn.guo@freescale.com>:
> Hi David,
>
> On Sat, Apr 02, 2011 at 12:57:14AM -0700, David Miller wrote:
>>
>> First, your patches never make it to the mailing list because the list
>> server rejects your postings, due to the fact that there are syntax
>> errors in your email headers:
>>
>> Illegal-Object: Syntax error in From: address found on vger.kernel.org:
>> From: Aisheng.Dong<b29396@freescale.com>
>> ^-missing end of mailbox
>>
> Yes, we were aware of that the mail did not get distributed by vger
> list. But we do not know why. Thanks for telling.
>
> I'm not quite sure about the "^" indication. Is it telling that there
> should be a space between display name and mail address?
We should not use A.B <>, instead should use A B <>.
Jason
>
> --
> Regards,
> Shawn
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* Re: [PATCH 1/1] net/fec: do not pass NULL dev to DMA API
From: Shawn Guo @ 2011-04-02 8:31 UTC (permalink / raw)
To: David Miller; +Cc: b29396, netdev, linux-arm-kernel
In-Reply-To: <20110402.005714.258110130.davem@davemloft.net>
Hi David,
On Sat, Apr 02, 2011 at 12:57:14AM -0700, David Miller wrote:
>
> First, your patches never make it to the mailing list because the list
> server rejects your postings, due to the fact that there are syntax
> errors in your email headers:
>
> Illegal-Object: Syntax error in From: address found on vger.kernel.org:
> From: Aisheng.Dong<b29396@freescale.com>
> ^-missing end of mailbox
>
Yes, we were aware of that the mail did not get distributed by vger
list. But we do not know why. Thanks for telling.
I'm not quite sure about the "^" indication. Is it telling that there
should be a space between display name and mail address?
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH 1/1] net/fec: do not pass NULL dev to DMA API
From: David Miller @ 2011-04-02 7:57 UTC (permalink / raw)
To: b29396; +Cc: netdev, linux-arm-kernel
In-Reply-To: <1301726391-7431-1-git-send-email-b29396@freescale.com>
First, your patches never make it to the mailing list because the list
server rejects your postings, due to the fact that there are syntax
errors in your email headers:
Illegal-Object: Syntax error in From: address found on vger.kernel.org:
From: Aisheng.Dong<b29396@freescale.com>
^-missing end of mailbox
Second, this patch does not apply to the current tree at all.
This bug has already been fixed and there are no cases where
a NULL device is passed to the DMA API interfaces any more.
^ permalink raw reply
* [PATCH 1/1] net/fec: do not pass NULL dev to DMA API
From: Aisheng.Dong @ 2011-04-02 6:39 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-arm-kernel
Fec will crash when DMABOUNCE is enabled.
Unable to handle kernel NULL pointer dereference at virtual address 000000bc
pgd = 80004000
[000000bc] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT
last sysfs file:
Modules linked in:
CPU: 0 Not tainted (2.6.35.3-00845-g204c152-dirty #112)
PC is at dma_map_single+0x2c/0x2a0
LR is at fec_enet_interrupt+0x1d4/0x450
The reason is DMA API of dmabounce needs the dev passed in is not NULL.
Here we'd always pass in a struct device if there is one available
for using DMA API to improve the code robustness sicne it may not
always work when passing a NULL dev.
Signed-off-by: Aisheng.Dong <b29396@freescale.com>
---
drivers/net/fec.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index cd0282d..89a2ba4 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -527,7 +527,7 @@ fec_enet_rx(struct net_device *dev)
dev->stats.rx_bytes += pkt_len;
data = (__u8*)__va(bdp->cbd_bufaddr);
- dma_unmap_single(NULL, bdp->cbd_bufaddr, bdp->cbd_datlen,
+ dma_unmap_single(&dev->dev, bdp->cbd_bufaddr, bdp->cbd_datlen,
DMA_FROM_DEVICE);
if (id_entry->driver_data & FEC_QUIRK_SWAP_FRAME)
@@ -552,7 +552,7 @@ fec_enet_rx(struct net_device *dev)
netif_rx(skb);
}
- bdp->cbd_bufaddr = dma_map_single(NULL, data, bdp->cbd_datlen,
+ bdp->cbd_bufaddr = dma_map_single(&dev->dev, data, bdp->cbd_datlen,
DMA_FROM_DEVICE);
rx_processing_done:
/* Clear the status flags for this buffer */
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] net: ethtool support to configure number of channels
From: Anirban Chakraborty @ 2011-04-02 5:47 UTC (permalink / raw)
To: Ben Hutchings
Cc: Amit Salecha, davem@davemloft.net, netdev@vger.kernel.org,
Ameen Rahman, Sucheta Chakraborty
In-Reply-To: <1301712946.10056.179.camel@localhost>
On Apr 1, 2011, at 7:55 PM, Ben Hutchings wrote:
> On Fri, 2011-04-01 at 21:36 -0500, Amit Salecha wrote:
>>> I'm not sure why you reduced this to a single count. If if the driver
>>> or hardware doesn't allow certain combinations of counts, it might be
>>> necessary to configure several types at the same time
>>>
>>>> +/* Channel ID is made up of a type */
>>>> +enum ethtool_channel_id {
>>>> + ETH_CHAN_TYPE_RX = 0x1,
>>>> + ETH_CHAN_TYPE_TX = 0x2
>>>> +};
>>> [...]
>>>
>>> enum ethtool_channel_id was meant to be an identifier of a specific
>>> channel. An enumeration of channel types should be named differently.
>>>
>>
>> I will name it as ethtool_channel_type. Any other suggestion ?
>>
>>> This also omits the 'combined' and 'other' types. Most multiqueue
>>> drivers pair up RX and TX queues so that most channels combine RX and
>>> TX
>>> work.
>>
>> 'combined' is ok, what is use of 'other' ?
>
> Could be link interrupts, SR-IOV coordination, or something else. Not
> something you'd likely be able to change, but it could be useful to know
> that some interrupts are allocated to them. Actually, that does mean it
> might be helpful for the 'get' operation to return a minimum value along
> with the maximum value.
Are you thinking of using the 'other' field as a way to a represent a 'virtual port'
that a VF could have. A virtual port could have a set of rx/tx rings, interrupts,
QoS parameters, MAC filters, VLAN ids etc. etc. A VF could have one or many such
channels. If thats the case, I would think that configuring these channels should
be done via a PF rather than on a VF. It is possible I could get you totally wrong here,
however it would be good to hear your thoughts.
-Anirban
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
^ permalink raw reply
* [PATCHv3 NEXT 1/1] net: ethtool support to configure number of channels
From: Amit Kumar Salecha @ 2011-04-02 4:58 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty, Ben Hutchings
o There exist ETHTOOL_GRXRINGS command for getting number of RX rings,
but it is tigtly coupled with RX flow hash configuration.
o Patches for qlcnic and netxen_nic driver supporting rx channel will follow
soon.
o This patch is reworked on Ben Hutchings "ethtool: NUMA affinity control" patch,
dropping the affinity control from it.
Ben Hutching:
o define 'combined' and 'other' types. Most multiqueue drivers pair up RX and TX
queues so that most channels combine RX and TX work.
o Please could you use a kernel-doc comment to describe the structure.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
include/linux/ethtool.h | 41 +++++++++++++++++++++++++++++++++++++++++
net/core/ethtool.c | 41 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index c8fcbdd..3c4d968 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -229,6 +229,42 @@ struct ethtool_ringparam {
__u32 tx_pending;
};
+/**
+ * struct ethtool_channels - configuring number of network channel
+ * @cmd: ETHTOOL_{G,S}CHANNELS
+ * @type: Channel type defined in ethtool_channel_type
+ * @max_XX: Read only. Maximum number of channel the driver support
+ * @XX_count: Valid values are in the range 1 to the "max_XX" counterpart above.
+ *
+ * This can be used to configure RX,TX and other channels.
+ */
+
+struct ethtool_channels {
+ __u32 cmd;
+ __u32 type;
+ __u32 max_rx;
+ __u32 max_tx;
+ __u32 max_other;
+ __u32 rx_count;
+ __u32 tx_count;
+ __u32 other_count;
+};
+
+/* Channel type */
+/* Channel type should be pass in type field of ethtool_channels.
+ * TYPE_ALL indicates set all channels to XX_count values.
+ * TYPE_RX and TYPE_TX is to get and set RX and TX channels correspondingly.
+ * TYPE_COMBINED is to set both RX and TX channels to rx_count and tx_count
+ * correspondingly. TYPE_OTHER is to configure other channel.
+ */
+enum ethtool_channel_type {
+ ETH_CHAN_TYPE_ALL = 0,
+ ETH_CHAN_TYPE_RX,
+ ETH_CHAN_TYPE_TX,
+ ETH_CHAN_TYPE_COMBINED,
+ ETH_CHAN_TYPE_OTHER,
+};
+
/* for configuring link flow control parameters */
struct ethtool_pauseparam {
__u32 cmd; /* ETHTOOL_{G,S}PAUSEPARAM */
@@ -802,6 +838,9 @@ struct ethtool_ops {
struct ethtool_rxfh_indir *);
int (*set_rxfh_indir)(struct net_device *,
const struct ethtool_rxfh_indir *);
+ int (*get_channels)(struct net_device *, struct ethtool_channels *);
+ int (*set_channels)(struct net_device *, struct ethtool_channels *);
+
};
#endif /* __KERNEL__ */
@@ -870,6 +909,8 @@ struct ethtool_ops {
#define ETHTOOL_GFEATURES 0x0000003a /* Get device offload settings */
#define ETHTOOL_SFEATURES 0x0000003b /* Change device offload settings */
+#define ETHTOOL_GCHANNELS 0x0000003c /* Get no of channels */
+#define ETHTOOL_SCHANNELS 0x0000003d /* Set no of channels */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 74ead9e..91c3c6d 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1441,6 +1441,41 @@ static int ethtool_set_ringparam(struct net_device *dev, void __user *useraddr)
return dev->ethtool_ops->set_ringparam(dev, &ringparam);
}
+static noinline_for_stack int ethtool_get_channels(struct net_device *dev,
+ void __user *useraddr)
+{
+ struct ethtool_channels channels;
+ int rc;
+
+ if (!dev->ethtool_ops->get_channels)
+ return -EOPNOTSUPP;
+
+ if (copy_from_user(&channels, useraddr, sizeof(channels)))
+ return -EFAULT;
+
+ rc = dev->ethtool_ops->get_channels(dev, &channels);
+ if (rc)
+ return rc;
+
+ if (copy_to_user(useraddr, &channels, sizeof(channels)))
+ return -EFAULT;
+ return 0;
+}
+
+static noinline_for_stack int ethtool_set_channels(struct net_device *dev,
+ void __user *useraddr)
+{
+ struct ethtool_channels channels;
+
+ if (!dev->ethtool_ops->set_channels)
+ return -EOPNOTSUPP;
+
+ if (copy_from_user(&channels, useraddr, sizeof(channels)))
+ return -EFAULT;
+
+ return dev->ethtool_ops->set_channels(dev, &channels);
+}
+
static int ethtool_get_pauseparam(struct net_device *dev, void __user *useraddr)
{
struct ethtool_pauseparam pauseparam = { ETHTOOL_GPAUSEPARAM };
@@ -1953,6 +1988,12 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
case ETHTOOL_SGRO:
rc = ethtool_set_one_feature(dev, useraddr, ethcmd);
break;
+ case ETHTOOL_GCHANNELS:
+ rc = ethtool_get_channels(dev, useraddr);
+ break;
+ case ETHTOOL_SCHANNELS:
+ rc = ethtool_set_channels(dev, useraddr);
+ break;
default:
rc = -EOPNOTSUPP;
}
--
1.7.3.2
^ permalink raw reply related
* [PATCHv2 NEXT 1/1] net: ethtool support to configure number of channels
From: Amit Kumar Salecha @ 2011-04-02 4:51 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty, Ben Hutchings
o Instead of cluttering struct ethtool_channels, defined channel type in
struct ethtool_channels, making it scalable for addition future channels.
Application needs to send different ioctl for each channel type.
o There exist ETHTOOL_GRXRINGS command for getting number of RX rings,
but it is tigtly coupled with RX flow hash configuration.
o New channel id can be added in ethtool_channel_id to make it configurable.
o Patches for qlcnic and netxen_nic driver supporting rx channel will follow
soon.
o This patch is reworked on Ben Hutchings "ethtool: NUMA affinity control" patch,
dropping the affinity control from it.
Ben Hutching:
o define 'combined' and 'other' types. Most multiqueue drivers pair up RX and TX
queues so that most channels combine RX and TX work.
o Please could you use a kernel-doc comment to describe the structure.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
include/linux/ethtool.h | 41 +++++++++++++++++++++++++++++++++++++++++
net/core/ethtool.c | 41 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index c8fcbdd..3c4d968 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -229,6 +229,42 @@ struct ethtool_ringparam {
__u32 tx_pending;
};
+/**
+ * struct ethtool_channels - configuring number of network channel
+ * @cmd: ETHTOOL_{G,S}CHANNELS
+ * @type: Channel type defined in ethtool_channel_type
+ * @max_XX: Read only. Maximum number of channel the driver support
+ * @XX_count: Valid values are in the range 1 to the "max_XX" counterpart above.
+ *
+ * This can be used to configure RX,TX and other channels.
+ */
+
+struct ethtool_channels {
+ __u32 cmd;
+ __u32 type;
+ __u32 max_rx;
+ __u32 max_tx;
+ __u32 max_other;
+ __u32 rx_count;
+ __u32 tx_count;
+ __u32 other_count;
+};
+
+/* Channel type */
+/* Channel type should be pass in type field of ethtool_channels.
+ * TYPE_ALL indicates set all channels to XX_count values.
+ * TYPE_RX and TYPE_TX is to get and set RX and TX channels correspondingly.
+ * TYPE_COMBINED is to set both RX and TX channels to rx_count and tx_count
+ * correspondingly. TYPE_OTHER is to configure other channel.
+ */
+enum ethtool_channel_type {
+ ETH_CHAN_TYPE_ALL = 0,
+ ETH_CHAN_TYPE_RX,
+ ETH_CHAN_TYPE_TX,
+ ETH_CHAN_TYPE_COMBINED,
+ ETH_CHAN_TYPE_OTHER,
+};
+
/* for configuring link flow control parameters */
struct ethtool_pauseparam {
__u32 cmd; /* ETHTOOL_{G,S}PAUSEPARAM */
@@ -802,6 +838,9 @@ struct ethtool_ops {
struct ethtool_rxfh_indir *);
int (*set_rxfh_indir)(struct net_device *,
const struct ethtool_rxfh_indir *);
+ int (*get_channels)(struct net_device *, struct ethtool_channels *);
+ int (*set_channels)(struct net_device *, struct ethtool_channels *);
+
};
#endif /* __KERNEL__ */
@@ -870,6 +909,8 @@ struct ethtool_ops {
#define ETHTOOL_GFEATURES 0x0000003a /* Get device offload settings */
#define ETHTOOL_SFEATURES 0x0000003b /* Change device offload settings */
+#define ETHTOOL_GCHANNELS 0x0000003c /* Get no of channels */
+#define ETHTOOL_SCHANNELS 0x0000003d /* Set no of channels */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 74ead9e..91c3c6d 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1441,6 +1441,41 @@ static int ethtool_set_ringparam(struct net_device *dev, void __user *useraddr)
return dev->ethtool_ops->set_ringparam(dev, &ringparam);
}
+static noinline_for_stack int ethtool_get_channels(struct net_device *dev,
+ void __user *useraddr)
+{
+ struct ethtool_channels channels;
+ int rc;
+
+ if (!dev->ethtool_ops->get_channels)
+ return -EOPNOTSUPP;
+
+ if (copy_from_user(&channels, useraddr, sizeof(channels)))
+ return -EFAULT;
+
+ rc = dev->ethtool_ops->get_channels(dev, &channels);
+ if (rc)
+ return rc;
+
+ if (copy_to_user(useraddr, &channels, sizeof(channels)))
+ return -EFAULT;
+ return 0;
+}
+
+static noinline_for_stack int ethtool_set_channels(struct net_device *dev,
+ void __user *useraddr)
+{
+ struct ethtool_channels channels;
+
+ if (!dev->ethtool_ops->set_channels)
+ return -EOPNOTSUPP;
+
+ if (copy_from_user(&channels, useraddr, sizeof(channels)))
+ return -EFAULT;
+
+ return dev->ethtool_ops->set_channels(dev, &channels);
+}
+
static int ethtool_get_pauseparam(struct net_device *dev, void __user *useraddr)
{
struct ethtool_pauseparam pauseparam = { ETHTOOL_GPAUSEPARAM };
@@ -1953,6 +1988,12 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
case ETHTOOL_SGRO:
rc = ethtool_set_one_feature(dev, useraddr, ethcmd);
break;
+ case ETHTOOL_GCHANNELS:
+ rc = ethtool_get_channels(dev, useraddr);
+ break;
+ case ETHTOOL_SCHANNELS:
+ rc = ethtool_set_channels(dev, useraddr);
+ break;
default:
rc = -EOPNOTSUPP;
}
--
1.7.3.2
^ permalink raw reply related
* Re: [Bug 32322] New: Kernel crashes randomly due to unknown reason
From: David Miller @ 2011-04-02 4:47 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: henrick19777, netdev
In-Reply-To: <alpine.DEB.2.00.1103312212360.9481@melkinpaasi.cs.helsinki.fi>
From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Thu, 31 Mar 2011 22:37:21 +0300 (EEST)
> [PATCH] tcp: len check is unnecessarily devastating, change to WARN_ON
>
> All callers are prepared to alloc failures anyway, so this error
> can safely be boomeranged to the callers domain without super
> bad consequences. ...At worst the connection might go into a state
> where each RTO tries to (unsuccessfully) re-fragment with such
> a mis-sized value and eventually dies.
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] sctp: malloc enough room for asconf-ack chunk
From: David Miller @ 2011-04-02 4:46 UTC (permalink / raw)
To: yjwei; +Cc: vladislav.yasevich, linux-sctp, netdev
In-Reply-To: <4D959E1F.80504@cn.fujitsu.com>
From: Wei Yongjun <yjwei@cn.fujitsu.com>
Date: Fri, 01 Apr 2011 17:42:55 +0800
> Sometime the ASCONF_ACK parameters can equal to the fourfold of
> ASCONF parameters, this only happend in some special case:
>
> ASCONF parameter is :
> Unrecognized Parameter (4 bytes)
> ASCONF_ACK parameter should be:
> Error Cause Indication parameter (8 bytes header)
> + Error Cause (4 bytes header)
> + Unrecognized Parameter (4bytes)
>
> Four 4bytes Unrecognized Parameters in ASCONF chunk will cause panic.
...
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] sctp: fix auth_hmacs field's length of struct sctp_cookie
From: David Miller @ 2011-04-02 4:46 UTC (permalink / raw)
To: yjwei; +Cc: vladislav.yasevich, linux-sctp, netdev
In-Reply-To: <4D959D2E.40605@cn.fujitsu.com>
From: Wei Yongjun <yjwei@cn.fujitsu.com>
Date: Fri, 01 Apr 2011 17:38:54 +0800
> auth_hmacs field of struct sctp_cookie is used for store
> Requested HMAC Algorithm Parameter, and each HMAC Identifier
> is 2 bytes, so the length should be:
> SCTP_AUTH_NUM_HMACS * sizeof(__u16) + 2
>
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] ROSE: prevent heap corruption with bad facilities
From: David Miller @ 2011-04-02 4:41 UTC (permalink / raw)
To: jbohac; +Cc: ben, drosenberg, ralf, netdev, security
In-Reply-To: <20110331180225.GA6677@midget.suse.cz>
From: Jiri Bohac <jbohac@suse.cz>
Date: Thu, 31 Mar 2011 20:02:25 +0200
> So, to get the old behaviour back:
Jiri, please do not submit two patches in one email, it's beyond
confusing.
Instead, please submit a proper two-patch series.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: convert sunhme/sungem network drivers to hw_features
From: David Miller @ 2011-04-02 3:58 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev
In-Reply-To: <20110331110135.BDFF913A69@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Thu, 31 Mar 2011 13:01:35 +0200 (CEST)
> Side effects:
> - TX offloads (HW csum, scatter-gather) can be toggled now
> - RX checksum is reported correctly now (it's always active)
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] veth: convert to hw_features
From: David Miller @ 2011-04-02 3:58 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev
In-Reply-To: <20110331110135.890D113A67@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Thu, 31 Mar 2011 13:01:35 +0200 (CEST)
> This should probably get TSO available as it's basically a loopback device.
> Offloads are left disabled by default - as before.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH v2] net: convert SMSC USB net drivers to hw_features
From: David Miller @ 2011-04-02 3:55 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, steve.glendinning
In-Reply-To: <20110331113921.8D7CC13909@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Thu, 31 Mar 2011 13:39:21 +0200 (CEST)
> [v1 introduced some warnings about unused local variables]
Thanks, I'll make sure to use this version.
^ permalink raw reply
* Re: [PATCH] jme: convert offload constraints to ndo_fix_features
From: David Miller @ 2011-04-02 3:55 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, cooldavid
In-Reply-To: <20110331110135.4649B13A66@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Thu, 31 Mar 2011 13:01:35 +0200 (CEST)
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH RESEND] net: convert xen-netfront to hw_features
From: David Miller @ 2011-04-02 3:54 UTC (permalink / raw)
To: mirq-linux
Cc: netdev, jeremy.fitzhardinge, konrad.wilk, Ian.Campbell, xen-devel,
virtualization
In-Reply-To: <20110331110136.03A1A13A6A@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Thu, 31 Mar 2011 13:01:35 +0200 (CEST)
> Not tested in any way. The original code for offload setting seems broken
> as it resets the features on every netback reconnect.
>
> This will set GSO_ROBUST at device creation time (earlier than connect time).
>
> RX checksum offload is forced on - so advertise as it is.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ 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