* Re: [PATCH] net: qmi_wwan: add ZTE MF821D
From: David Miller @ 2012-07-18 16:41 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb, tschaefer
In-Reply-To: <1342091906-30045-1-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Thu, 12 Jul 2012 13:18:26 +0200
> Sold by O2 (telefonica germany) under the name "LTE4G"
>
> Tested-by: Thomas Schäfer <tschaefer@t-online.de>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
Applied to net-next, thanks.
^ permalink raw reply
* [PATCH 3/3] tilegx net: use eth_hw_addr_random(), not random_ether_addr()
From: Chris Metcalf @ 2012-07-18 16:23 UTC (permalink / raw)
To: David S. Miller, netdev, linux-kernel
In-Reply-To: <201207181640.q6IGet7P007227@lab-41.internal.tilera.com>
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
---
drivers/net/ethernet/tile/tilegx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/tile/tilegx.c b/drivers/net/ethernet/tile/tilegx.c
index f78effc..4e2a162 100644
--- a/drivers/net/ethernet/tile/tilegx.c
+++ b/drivers/net/ethernet/tile/tilegx.c
@@ -1851,7 +1851,7 @@ static void tile_net_dev_init(const char *name, const uint8_t *mac)
memcpy(dev->dev_addr, mac, 6);
dev->addr_len = 6;
} else {
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
}
/* Register the network device. */
--
1.7.10.3
^ permalink raw reply related
* [PATCH 2/3] tilegx net driver: handle payload data not in frags
From: Chris Metcalf @ 2012-07-11 18:08 UTC (permalink / raw)
To: David S. Miller, netdev, linux-kernel
In-Reply-To: <201207181640.q6IGet7P007227@lab-41.internal.tilera.com>
The original driver implementation assumed that for TSO, all the
payload data would be in the frags. This isn't always true; change
the driver to support payload data at skb->data between
"skb_transport_offset(skb) + tcp_hdrlen(skb)" and "skb->hdr_len",
followed by the data in the frags.
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
---
drivers/net/ethernet/tile/tilegx.c | 36 ++++++++++++++++++------------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/tile/tilegx.c b/drivers/net/ethernet/tile/tilegx.c
index c7bde28..f78effc 100644
--- a/drivers/net/ethernet/tile/tilegx.c
+++ b/drivers/net/ethernet/tile/tilegx.c
@@ -1333,11 +1333,12 @@ static s64 tile_net_equeue_try_reserve(struct net_device *dev,
static int tso_count_edescs(struct sk_buff *skb)
{
struct skb_shared_info *sh = skb_shinfo(skb);
- unsigned int data_len = skb->data_len;
+ unsigned int sh_len = skb_transport_offset(skb) + tcp_hdrlen(skb);
+ unsigned int data_len = skb->data_len + skb->hdr_len - sh_len;
unsigned int p_len = sh->gso_size;
long f_id = -1; /* id of the current fragment */
- long f_size = -1; /* size of the current fragment */
- long f_used = -1; /* bytes used from the current fragment */
+ long f_size = skb->hdr_len; /* size of the current fragment */
+ long f_used = sh_len; /* bytes used from the current fragment */
long n; /* size of the current piece of payload */
int num_edescs = 0;
int segment;
@@ -1382,13 +1383,14 @@ static void tso_headers_prepare(struct sk_buff *skb, unsigned char *headers,
struct skb_shared_info *sh = skb_shinfo(skb);
struct iphdr *ih;
struct tcphdr *th;
- unsigned int data_len = skb->data_len;
+ unsigned int sh_len = skb_transport_offset(skb) + tcp_hdrlen(skb);
+ unsigned int data_len = skb->data_len + skb->hdr_len - sh_len;
unsigned char *data = skb->data;
- unsigned int ih_off, th_off, sh_len, p_len;
+ unsigned int ih_off, th_off, p_len;
unsigned int isum_seed, tsum_seed, id, seq;
long f_id = -1; /* id of the current fragment */
- long f_size = -1; /* size of the current fragment */
- long f_used = -1; /* bytes used from the current fragment */
+ long f_size = skb->hdr_len; /* size of the current fragment */
+ long f_used = sh_len; /* bytes used from the current fragment */
long n; /* size of the current piece of payload */
int segment;
@@ -1397,14 +1399,13 @@ static void tso_headers_prepare(struct sk_buff *skb, unsigned char *headers,
th = tcp_hdr(skb);
ih_off = skb_network_offset(skb);
th_off = skb_transport_offset(skb);
- sh_len = th_off + tcp_hdrlen(skb);
p_len = sh->gso_size;
/* Set up seed values for IP and TCP csum and initialize id and seq. */
isum_seed = ((0xFFFF - ih->check) +
(0xFFFF - ih->tot_len) +
(0xFFFF - ih->id));
- tsum_seed = th->check + (0xFFFF ^ htons(skb->len));
+ tsum_seed = th->check + (0xFFFF ^ htons(sh_len + data_len));
id = ntohs(ih->id);
seq = ntohl(th->seq);
@@ -1476,21 +1477,22 @@ static void tso_egress(struct net_device *dev, gxio_mpipe_equeue_t *equeue,
{
struct tile_net_priv *priv = netdev_priv(dev);
struct skb_shared_info *sh = skb_shinfo(skb);
- unsigned int data_len = skb->data_len;
+ unsigned int sh_len = skb_transport_offset(skb) + tcp_hdrlen(skb);
+ unsigned int data_len = skb->data_len + skb->hdr_len - sh_len;
unsigned int p_len = sh->gso_size;
gxio_mpipe_edesc_t edesc_head = { { 0 } };
gxio_mpipe_edesc_t edesc_body = { { 0 } };
long f_id = -1; /* id of the current fragment */
- long f_size = -1; /* size of the current fragment */
- long f_used = -1; /* bytes used from the current fragment */
+ long f_size = skb->hdr_len; /* size of the current fragment */
+ long f_used = sh_len; /* bytes used from the current fragment */
+ void *f_data = skb->data;
long n; /* size of the current piece of payload */
unsigned long tx_packets = 0, tx_bytes = 0;
- unsigned int csum_start, sh_len;
+ unsigned int csum_start;
int segment;
/* Prepare to egress the headers: set up header edesc. */
csum_start = skb_checksum_start_offset(skb);
- sh_len = skb_transport_offset(skb) + tcp_hdrlen(skb);
edesc_head.csum = 1;
edesc_head.csum_start = csum_start;
edesc_head.csum_dest = csum_start + skb->csum_offset;
@@ -1502,7 +1504,6 @@ static void tso_egress(struct net_device *dev, gxio_mpipe_equeue_t *equeue,
/* Egress all the edescs. */
for (segment = 0; segment < sh->gso_segs; segment++) {
- void *va;
unsigned char *buf;
unsigned int p_used = 0;
@@ -1521,10 +1522,9 @@ static void tso_egress(struct net_device *dev, gxio_mpipe_equeue_t *equeue,
f_id++;
f_size = sh->frags[f_id].size;
f_used = 0;
+ f_data = tile_net_frag_buf(&sh->frags[f_id]);
}
- va = tile_net_frag_buf(&sh->frags[f_id]) + f_used;
-
/* Use bytes from the current fragment. */
n = p_len - p_used;
if (n > f_size - f_used)
@@ -1533,7 +1533,7 @@ static void tso_egress(struct net_device *dev, gxio_mpipe_equeue_t *equeue,
p_used += n;
/* Egress a piece of the payload. */
- edesc_body.va = va_to_tile_io_addr(va);
+ edesc_body.va = va_to_tile_io_addr(f_data) + f_used;
edesc_body.xfer_size = n;
edesc_body.bound = !(p_used < p_len);
gxio_mpipe_equeue_put_at(equeue, edesc_body, slot);
--
1.7.10.3
^ permalink raw reply related
* Re: [PATCH v2] netns: correctly use per-netns ipv4 sysctl_tcp_mem
From: David Miller @ 2012-07-18 16:41 UTC (permalink / raw)
To: h.huangqiang-hv44wF8Li93QT0dZR+AlfA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
In-Reply-To: <4FFE99EE.70003-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
From: Huang Qiang <h.huangqiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Date: Thu, 12 Jul 2012 17:33:34 +0800
> From: Yang Zhenzhang <yangzhenzhang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>
> Now, kernel allows each net namespace to independently set up its levels
> for tcp memory pressure thresholds.
>
> But it seems there is a bug, as using the following steps:
>
> [root@host socket]# lxc-start -n test -f config /bin/bash
> [root@net-test socket]# ip route add default via 192.168.58.2
> [root@net-test socket]# echo 0 0 0 > /proc/sys/net/ipv4/tcp_mem
> [root@net-test socket]# scp root-Q0ErXNX1RuabR28l3DCWlg@public.gmane.org:/home/tcp_mem_test .
>
> and it still can transport the "tcp_mem_test" file which we hope it
> would not.
>
> It's because inet_init() (net/ipv4/af_inet.c)initialize the tcp_prot.sysctl_mem:
> tcp_prot.sysctl_mem = init_net.ipv4.sysctl_tcp_mem;
>
> So when the protocal is TCP, sk->sk_prot->sysctl_mem(following code)
> always use the ipv4 sysctl_tcp_mem of init_net namespace rather than
> it's own net namespace.
> This patch simply set "prot" equal to net->ipv4.sysctl_tcp_mem when
> the protocol type is TCP.
>
> Signed-off-by: Yang Zhenzhang <yangzhenzhang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Huang Qiang <h.huangqiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
This patch doesn't apply cleanly to net-next, please respin it.
Thank you.
^ permalink raw reply
* [PATCH 0/3] net: various tilegx networking fixes
From: Chris Metcalf @ 2012-07-01 18:43 UTC (permalink / raw)
To: David S. Miller, netdev, linux-kernel
This series of fixes corrects a few bugs or style issues observed
in the tilegx network driver.
David, once any potential issues with these patches are resolved,
would you prefer to take them from email, pull them from my net tree,
or have me push them as part of the tile tree?
The tree is at:
git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile.git net
Chris Metcalf (3):
net: tilegx driver bugfix (be explicit about percpu queue number)
tilegx net driver: handle payload data not in frags
tilegx net: use eth_hw_addr_random(), not random_ether_addr()
drivers/net/ethernet/tile/tilegx.c | 61 ++++++++++++++++++++----------------
1 file changed, 34 insertions(+), 27 deletions(-)
Thanks!
^ permalink raw reply
* Re: [RFC PATCH] net: cgroup: null ptr dereference in netprio cgroup during init
From: David Miller @ 2012-07-18 16:39 UTC (permalink / raw)
To: nhorman; +Cc: john.r.fastabend, gaofeng, mark.d.rustad, netdev, eric.dumazet
In-Reply-To: <20120718163721.GH25563@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Wed, 18 Jul 2012 12:37:21 -0400
> On Wed, Jul 18, 2012 at 08:53:03AM -0700, David Miller wrote:
>> From: Neil Horman <nhorman@tuxdriver.com>
>> Date: Wed, 18 Jul 2012 11:25:20 -0400
>>
>> > Yeah, I see what you mean. Seems like what we need is to either:
>> > 1) move cgroup_init to later in the boot process. If you're not early_init,
>> > then I don't see why the subsystem can't wait until later in the boot process
>> > (i.e. make cgroup_init a late_initcall or some such).
>> >
>> > or
>> >
>> > 2) Allow module based cgroups to flag themselves as needing late init after the
>> > rest of the kernel has booted.
>>
>> These are way too complicated compared to John's currently proposed
>> fix for this recently introduced regression.
>>
>> I want a one liner which I can prove is going to remove the crash.
>>
>> All of this talk of rearranging initcall ordering for cgroup stuff
>> is too ambitious this late in the -rc.
>>
> Thats a fair point. I'd still like to look into this further, as I think theres
> a more correct answer than the current proposal.
I totally agree, and such investigations can target net-next.
> But since we're looking to fix a specific problem at the end of rc:
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Thanks Neil.
John can you respin your patch with the minor change I asked for? I'll
apply it as soon as you send it.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH] net: cgroup: null ptr dereference in netprio cgroup during init
From: Neil Horman @ 2012-07-18 16:37 UTC (permalink / raw)
To: David Miller
Cc: john.r.fastabend, gaofeng, mark.d.rustad, netdev, eric.dumazet
In-Reply-To: <20120718.085303.2226773601811613983.davem@davemloft.net>
On Wed, Jul 18, 2012 at 08:53:03AM -0700, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Wed, 18 Jul 2012 11:25:20 -0400
>
> > Yeah, I see what you mean. Seems like what we need is to either:
> > 1) move cgroup_init to later in the boot process. If you're not early_init,
> > then I don't see why the subsystem can't wait until later in the boot process
> > (i.e. make cgroup_init a late_initcall or some such).
> >
> > or
> >
> > 2) Allow module based cgroups to flag themselves as needing late init after the
> > rest of the kernel has booted.
>
> These are way too complicated compared to John's currently proposed
> fix for this recently introduced regression.
>
> I want a one liner which I can prove is going to remove the crash.
>
> All of this talk of rearranging initcall ordering for cgroup stuff
> is too ambitious this late in the -rc.
>
Thats a fair point. I'd still like to look into this further, as I think theres
a more correct answer than the current proposal. But since we're looking to fix a
specific problem at the end of rc:
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [net-next PATCH 00/02] net/ipv4: Add support for new tunnel type VTI.
From: David Miller @ 2012-07-18 16:36 UTC (permalink / raw)
To: saurabh.mohan; +Cc: netdev
In-Reply-To: <20120717194442.GA3333@debian-saurabh-64.vyatta.com>
From: Saurabh <saurabh.mohan@vyatta.com>
Date: Tue, 17 Jul 2012 12:44:42 -0700
>
>
> I have accommodated all the style comments so far. If there are any more
> style comments then send all your feedback in one email rather than in bits
> and pieces.
>
> IPv6 support has not yet been developed. Once I have it developed and tested
> I'll submit it as well. If this feature will not be accepted without IPv6
> then let me know and I'll stop wasting my time.
>
> Incorporated David and Steffen's comments.
> Resubmitting after taking into account review comments:
> The VTI tunnel is applicable to esp, ah and ipcomp.
All applied.
Please post the ipv6 side soon, thank you.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Changes in qlcnic and qlge maintainers list
From: David Miller @ 2012-07-18 16:34 UTC (permalink / raw)
To: anirban.chakraborty; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1342552929-4529-1-git-send-email-anirban.chakraborty@qlogic.com>
From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Date: Tue, 17 Jul 2012 15:22:09 -0400
> From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
>
> Please apply.
>
> Thanks.
>
> Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] asix: Fix return value in AX88172A driver bind function
From: David Miller @ 2012-07-18 16:33 UTC (permalink / raw)
To: christian.riesch; +Cc: netdev
In-Reply-To: <1342609012-3075-1-git-send-email-christian.riesch@omicron.at>
From: Christian Riesch <christian.riesch@omicron.at>
Date: Wed, 18 Jul 2012 12:56:52 +0200
> Return -ENOTSUPP if the initialization fails because the
> device is configured for a mode that is not supported by the driver.
>
> Signed-off-by: Christian Riesch <christian.riesch@omicron.at>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] tcp: refine SYN handling in tcp_validate_incoming
From: David Miller @ 2012-07-18 16:32 UTC (permalink / raw)
To: eric.dumazet; +Cc: subramanian.vijay, netdev, kkiran
In-Reply-To: <1342564170.2626.1243.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 18 Jul 2012 00:29:30 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Followup of commit 0c24604b68fc (tcp: implement RFC 5961 4.2)
>
> As reported by Vijay Subramanian, we should send a challenge ACK
> instead of a dup ack if a SYN flag is set on a packet received out of
> window.
>
> This permits the ratelimiting to work as intended, and to increase
> correct SNMP counters.
>
> Suggested-by: Vijay Subramanian <subramanian.vijay@gmail.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Acked-by: Vijay Subramanian <subramanian.vijay@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bonding: refine IFF_XMIT_DST_RELEASE capability
From: David Miller @ 2012-07-18 16:32 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, fubar, andy, therbert
In-Reply-To: <1342563588.2626.1224.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 18 Jul 2012 00:19:48 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Some workloads greatly benefit of IFF_XMIT_DST_RELEASE capability
> on output net device, avoiding dirtying dst refcount.
>
> bonding currently disables IFF_XMIT_DST_RELEASE unconditionally.
>
> If all slaves have the IFF_XMIT_DST_RELEASE bit set, then
> bonding master can also have it in its priv_flags
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: qmi_wwan: make dynamic device IDs work
From: David Miller @ 2012-07-18 16:32 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb
In-Reply-To: <1342559672-5893-1-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Tue, 17 Jul 2012 23:14:32 +0200
> The usbnet API use the device ID table to store a pointer to
> a minidriver. Setting a generic pointer for dynamic device
> IDs will in most cases make them work as expected. usbnet
> will otherwise treat the dynamic IDs as blacklisted. That is
> rarely useful.
>
> There is no standard class describing devices supported by
> this driver, and most vendors don't even provide enough
> information to allow vendor specific wildcard matching. The
> result is that most of the supported devices must be
> explicitly listed in the device table. Allowing dynamic IDs
> to work both simplifies testing and verification of new
> devices, and provides a way for end users to use a device
> before the ID is added to the driver.
>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v3] ipv6: add ipv6_addr_hash() helper
From: Eric Dumazet @ 2012-07-18 16:30 UTC (permalink / raw)
To: David Miller; +Cc: joe, netdev, andrewmcgr, dave.taht, therbert
In-Reply-To: <20120718.091928.492512069081953171.davem@davemloft.net>
On Wed, 2012-07-18 at 09:19 -0700, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Wed, 18 Jul 2012 09:16:47 -0700 (PDT)
>
> >
> > Just to clarify, I made sure to use this version.
>
> Did you actually try to compile this?
>
> net/ipv6/addrconf.c already has a function named ipv6_addr_hash()
> and you didn't remove it in your patch.
Oops, sorry, will send a v4 then.
^ permalink raw reply
* Re: [PATCH v2] b44: add 64 bit stats
From: David Miller @ 2012-07-18 16:30 UTC (permalink / raw)
To: eric.dumazet; +Cc: kgroeneveld, netdev
In-Reply-To: <1342583402.2626.1376.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 18 Jul 2012 05:50:02 +0200
> On Tue, 2012-07-17 at 23:46 -0400, Kevin Groeneveld wrote:
>> From: Kevin Groeneveld <kgroeneveld@gmail.com>
>>
>> Add support for 64 bit stats to Broadcom b44 ethernet driver.
>>
>> Signed-off-by: Kevin Groeneveld <kgroeneveld@gmail.com>
>> ---
>> v2: use u64_stats_fetch_begin_bh/u64_stats_fetch_retry_bh instead of
>> u64_stats_fetch_begin/u64_stats_fetch_retry as stats update happens in a
>> timer interrupt
>
> Seems good this time, thanks
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/2] be2net fixes
From: David Miller @ 2012-07-18 16:28 UTC (permalink / raw)
To: padmanabh.ratnakar; +Cc: netdev
In-Reply-To: <9a423faa-bc47-459e-a59b-182dd94b8465@exht1.ad.emulex.com>
From: Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
Date: Wed, 18 Jul 2012 18:21:45 +0530
> Driver fixes for recent Lancer FW changes.
Both applied, thanks.
^ permalink raw reply
* Re: [RFC PATCH] net: cgroup: null ptr dereference in netprio cgroup during init
From: David Miller @ 2012-07-18 16:26 UTC (permalink / raw)
To: john.r.fastabend; +Cc: gaofeng, nhorman, mark.d.rustad, netdev, eric.dumazet
In-Reply-To: <20120718003316.2979.49278.stgit@jf-dev1-dcblab>
From: John Fastabend <john.r.fastabend@intel.com>
Date: Tue, 17 Jul 2012 17:33:16 -0700
> When the netprio cgroup is built in the kernel cgroup_init will call
> cgrp_create which eventually calls update_netdev_tables. This is
> being called before do_initcalls() so a null ptr dereference occurs
> on init_net.
>
> This patch adds a check on init_net.count to verify the structure
> has been initialized. The failure was introduced here,
>
> commit ef209f15980360f6945873df3cd710c5f62f2a3e
> Author: Gao feng <gaofeng@cn.fujitsu.com>
> Date: Wed Jul 11 21:50:15 2012 +0000
>
> net: cgroup: fix access the unallocated memory in netprio cgroup
>
> Tested with ping with netprio_cgroup as a module and built in.
>
> Marked RFC for now I think DaveM might have a reason why this needs
> some improvement.
>
> Reported-by: Mark Rustad <mark.d.rustad@intel.com>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
John, just so I can sleep better at night, can you add an explicit
initializer to init_net in net/core/net_namespace.c in this patch
so that "count" is explicitly set to ATOMIC_INIT(0)?
This is done elsewhere in the tree for similar situations.
Otherwise this patch looks great, thanks a lot.
^ permalink raw reply
* Re: [RFC] r8169 : why SG / TX checksum are default disabled
From: David Miller @ 2012-07-18 16:23 UTC (permalink / raw)
To: hayeswang; +Cc: romieu, eric.dumazet, netdev
In-Reply-To: <AC35CD5731C3479B9BF5E53BF541A81F@realtek.com.tw>
From: hayeswang <hayeswang@realtek.com>
Date: Wed, 18 Jul 2012 14:45:55 +0800
> Francois Romieu [mailto:romieu@fr.zoreil.com]
> [...]
>
>> Hayes, should we not add into the kernel driver something similar to
>> the rtl8168_start_xmit::skb_checksum_help stuff in Realtek's
>> 8168 driver ?
>> There seems to be a bug for (skb->len < 60 && RTL_GIGA_MAC_VER_34.
>
> For RTL8168E-VL (RTL_GIGA_MAC_VER_34), the hardware wouldn't send the packet
> with the length less than 60 bytes. The hardware should pad this kind of packet
> to 60 bytes, but it wouldn't. Therefore, the software has to pad the packet to
> 60 bytes. However, the hw checksum would be incorrect for the modified packet,
> so the software checksum is necessary.
I wonder how the hardware checksum can be incorrectly calculated if the padding
is done with zeros?
^ permalink raw reply
* Re: [net-next 0/6][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-07-18 16:21 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1342578045-17778-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 17 Jul 2012 19:20:39 -0700
> This series contains updates to ixgbe & ixgbevf.
>
> The following are changes since commit 5abf7f7e0f6bdbfcac737f636497d7016d9507eb:
> ipv4: fix rcu splat
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Pulled, thanks Jeff.
^ permalink raw reply
* Re: pull request: sfc-next 2012-07-17
From: Ben Hutchings @ 2012-07-18 16:19 UTC (permalink / raw)
To: David Miller; +Cc: linux-net-drivers, netdev
In-Reply-To: <20120718.091010.2180226373071597034.davem@davemloft.net>
On Wed, 2012-07-18 at 09:10 -0700, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Tue, 17 Jul 2012 18:05:40 +0100
>
> > The following changes since commit 141e369de698f2e17bf716b83fcc647ddcb2220c:
> >
> > xfrm: Initialize the struct xfrm_dst behind the dst_enty field (2012-07-14 00:29:12 -0700)
> >
> > are available in the git repository at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc-next.git for-davem
> >
> > (commit c2dbab39db1c3c2ccbdbb2c6bac6f07cc7a7c1f6)
> >
> > 1. Fix potential badness when running a self-test with SR-IOV enabled.
> > 2. Fix calculation of some interface statistics that could run backward.
> > 3. Miscellaneous cleanup.
>
> Looks good, pulled, thanks Ben.
>
> Out of curiosity, why the conversion to the generic DMA interfaces?
> Do you plan on using something uniquely provided by them vs. the PCI
> specific DMA interfaces (ability to specify GFP flags, stuff like
> that) or do you really plan on having non-PCI devices in the future?
Some DMA operations were already converted because GFP_KERNEL was wanted
or as part of the skb frags API. I changed the rest to be consistent;
I'm not aware of any plans for non-PCI devices.
Ben.
--
Ben Hutchings, Staff 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: [PATCH net-next v3] ipv6: add ipv6_addr_hash() helper
From: David Miller @ 2012-07-18 16:19 UTC (permalink / raw)
To: eric.dumazet; +Cc: joe, netdev, andrewmcgr, dave.taht, therbert
In-Reply-To: <20120718.091647.2208692760443941786.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 18 Jul 2012 09:16:47 -0700 (PDT)
>
> Just to clarify, I made sure to use this version.
Did you actually try to compile this?
net/ipv6/addrconf.c already has a function named ipv6_addr_hash()
and you didn't remove it in your patch.
^ permalink raw reply
* Re: [PATCH net-next v3] ipv6: add ipv6_addr_hash() helper
From: David Miller @ 2012-07-18 16:16 UTC (permalink / raw)
To: eric.dumazet; +Cc: joe, netdev, andrewmcgr, dave.taht, therbert
In-Reply-To: <1342621670.2626.2818.camel@edumazet-glaptop>
Just to clarify, I made sure to use this version.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: add ipv6_addr_hash() helper
From: David Miller @ 2012-07-18 16:16 UTC (permalink / raw)
To: eric.dumazet; +Cc: joe, netdev, andrewmcgr, dave.taht, therbert
In-Reply-To: <1342620841.2626.2786.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 18 Jul 2012 16:14:01 +0200
> but hash_long() on 64bit sounds a bit expensive for our needs...
Agreed.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: add ipv6_addr_hash() helper
From: David Miller @ 2012-07-18 16:15 UTC (permalink / raw)
To: eric.dumazet; +Cc: David.Laight, netdev, andrewmcgr, dave.taht, therbert
In-Reply-To: <1342620366.2626.2764.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 18 Jul 2012 16:06:06 +0200
> [PATCH net-next v2] ipv6: add ipv6_addr_hash() helper
>
> Introduce ipv6_addr_hash() helper doing a XOR on all bits
> of an IPv6 address, with an optimized x86_64 version.
>
> Use it in flow dissector, as suggested by Andrew McGregor,
> to reduce hash collision probabilities in fq_codel (and other
> users of flow dissector)
>
> Use it in ip6_tunnel.c and use more bit shuffling, as suggested
> by David Laight, as existing hash was ignoring most of them.
>
> Use it in sunrpc and use more bit shuffling, using hash_32().
>
> As cleanup, use it in net/ipv4/tcp_metrics.c
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Andrew McGregor <andrewmcgr@gmail.com>
Looks good, applied.
^ permalink raw reply
* Re: [PATCH net-next 0/2] Pull request for 'davem-next.r8169' branch
From: David Miller @ 2012-07-18 16:11 UTC (permalink / raw)
To: romieu; +Cc: netdev, hayeswang
In-Reply-To: <cover.1342562326.git.romieu@fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Wed, 18 Jul 2012 00:09:42 +0200
> Please pull from branch 'davem-next.r8169' in repository
>
> git://violet.fr.zoreil.com/romieu/linux davem-next.r8169
>
> to get the changes below.
Pulled, thanks Francois.
^ 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