* Re: Should we report bus width/speed via ethtool?
From: David Miller @ 2012-12-06 0:01 UTC (permalink / raw)
To: greearb; +Cc: netdev, e1000-devel
In-Reply-To: <50BFD417.7070306@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Wed, 05 Dec 2012 15:09:11 -0800
> On 12/05/2012 02:36 PM, David Miller wrote:
>> From: Ben Greear <greearb@candelatech.com>
>> Date: Wed, 05 Dec 2012 13:35:01 -0800
>>
>>> It seems the only way to get the current pci-e bus speed & width
>>> in ixgbe (and probably many other NICs) is by parsing output
>>> of lspci -vvv.
>>>
>>> I'd personally find it easier if this info were available via
>>> ethtool API.
>>
>> You could just as easily have ethtool determine the PCI device
>> location (using existing facilities) and fetch the PCI-e info from the
>> PCI sysfs files.
>
> Any particular sysfs file? I've been grubbing around in there
> and I don't see anything that specifies bus width or speed..
>
> Maybe it's some binary blob that needs decoding?
lspci might be a good place to figure this out :-) It's probably
grovelling around in PCI config space to determine these things.
^ permalink raw reply
* Re: Should we report bus width/speed via ethtool?
From: Rick Jones @ 2012-12-06 0:08 UTC (permalink / raw)
To: David Miller; +Cc: greearb, netdev, e1000-devel
In-Reply-To: <20121205.190121.1400827550469329286.davem@davemloft.net>
On 12/05/2012 04:01 PM, David Miller wrote:
> lspci might be a good place to figure this out :-) It's probably
> grovelling around in PCI config space to determine these things.
And if not lspci, "pcitop" used to grub around for such things, though
its source may be rather moldy. I'm sure though that if various chipset
providers were willing to document their PCI performance counters,
*someone* would be happy to bring pcitop into the present day...
happy benchmarking,
rick jones
^ permalink raw reply
* Re: Should we report bus width/speed via ethtool?
From: Brice Goglin @ 2012-12-06 0:20 UTC (permalink / raw)
To: greearb; +Cc: netdev, e1000-devel
In-Reply-To: <20121205.190121.1400827550469329286.davem@davemloft.net>
Le 05/12/2012 16:01, David Miller a écrit :
> lspci might be a good place to figure this out :-) It's probably
> grovelling around in PCI config space to determine these things.
Right, it looks from PCI_EXP_LNKSTA in the config space (only works as
root). Here's how we do the same in hwloc (using the pciutils lib
underneath):
https://svn.open-mpi.org/trac/hwloc/browser/trunk/src/topology-libpci.c#L399
Brice
^ permalink raw reply
* Re: ksoftirqd 100% after disabling IPv4 route cache on high pps.
From: 叶雨飞 @ 2012-12-06 0:34 UTC (permalink / raw)
Cc: netdev
In-Reply-To: <CAJygYd0-tLRJ6wnzKhXEL7W8hJJzKr=YST_cQxyvHvOKprcHjQ@mail.gmail.com>
Thanks Eric!
Following is only to help someone else who may run into the problem
and searching for options:
the ksoftirqd load is generated by route lookup subrouting. since this
is DDOS traffic we are dealing (more than 10x of our normal PPS) and I
have a fixed number of destinations, I've tested that I can filter
them efficiently in mangle table PREROUTING chain, and use hashlimit
to limit pps to send to the routing subsystem, ksoftirq problem is
gone and no kernel upgraded is needed until the inevitable.
Cheers.
On Wed, Dec 5, 2012 at 4:32 PM, 叶雨飞 <sunyucong@gmail.com> wrote:
> Thanks Eric!
>
> Following is only to help someone else who may run into the problem and
> searching for options:
>
> the ksoftirqd load is generated by route lookup subrouting. since this is
> DDOS traffic we are dealing (more than 10x of our normal PPS) and I have a
> fixed number of destinations, I've tested that I can filter them efficiently
> in mangle table PREROUTING chain, and use hashlimit to limit pps to send to
> the routing subsystem, ksoftirq problem is gone and no kernel upgraded is
> needed until the inevitable.
>
> Cheers.
>
>
> On Wed, Dec 5, 2012 at 3:48 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>
>> On Wed, 2012-12-05 at 13:22 -0800, 叶雨飞 wrote:
>> > Hi Eric,
>> >
>> > After disabling the route cache, I found a forwarding performance
>> > problem (inevitable ?). Basically the kernel couldn't keep up under
>> > about 100k pps and ksoftirqd is dominating the CPU. This problem went
>> > away right away if I do
>> >
>> > echo 1 > rt_cache_rebuild_count
>> >
>> > and comes back as soon as i do echo -1 > rt_cache_rebuild_count.
>> >
>> > I then tried to use RPS/RFS to share the load on to mulitple cpus
>> > (since ksoftirqd is only using 1 core, clearly). but that has little
>> > effect.
>> >
>> > Is there some tweaks/patches you recommend?
>>
>> Yes, upgrade your kernel to 3.6 or 3.7, this problem has been solved for
>> good. No more IP route cache and good performance.
>>
>>
>>
>
^ permalink raw reply
* Re: Should we report bus width/speed via ethtool?
From: Ben Greear @ 2012-12-06 0:44 UTC (permalink / raw)
To: Brice Goglin; +Cc: netdev, e1000-devel
In-Reply-To: <50BFE4D2.90707@inria.fr>
On 12/05/2012 04:20 PM, Brice Goglin wrote:
> Le 05/12/2012 16:01, David Miller a écrit :
>> lspci might be a good place to figure this out :-) It's probably
>> grovelling around in PCI config space to determine these things.
>
> Right, it looks from PCI_EXP_LNKSTA in the config space (only works as
> root). Here's how we do the same in hwloc (using the pciutils lib
> underneath):
>
> https://svn.open-mpi.org/trac/hwloc/browser/trunk/src/topology-libpci.c#L399
Thanks..but it seems easier to just parse the text output of lspci -vvv
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [Suggestion] net/atm : for sprintf, need check the total write length whether larger than a page.
From: Chen Gang @ 2012-12-06 1:15 UTC (permalink / raw)
To: chas williams - CONTRACTOR; +Cc: David Miller, netdev
In-Reply-To: <20121205095503.6d1c083d@thirdoffive.cmf.nrl.navy.mil>
于 2012年12月05日 22:55, chas williams - CONTRACTOR 写道:
> On Wed, 05 Dec 2012 13:59:26 +0800
>
> it doesn't seem like optimizing for this corner case is a huge
> concern. the list cannot be infinitely long.
>
ok.
>>>>
>>>> By the way:
>>>> will it be better that always let "\n" at the end ?
>>>> (if count == PAGE_SIZE in a loop, we can not let "\n" at the end).
>>>
>>> oh, sorry ! count will never >= PAGE_SIZE.
>>>
>>> I think let "PAGE_SIZE - 2" instead of "PAGE_SIZE" in the loop, so we
>>> can make the room for the end of "\n".
>>>
>>>
>>>
>> sorry, "PAGE_SIZE - 1" is enough, not need "PAGE_SIZE - 2".
>
> did you mean '\0' instead of '\n'? scnprintf() considers the trailing
> '\0' when formatting.
no, originally, the end is "\n\0".
I prefer we still compatible "\n" when the contents are very large.
if count already == (PAGE_SIZE - 1), we have no chance to append "\n" to the end.
- pos += sprintf(pos, "\n");
+ count += scnprintf(buf + count, PAGE_SIZE - count, "\n");
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: [RFT PATCH] 8139cp: properly support change of MTU values [v2]
From: David Woodhouse @ 2012-12-06 1:34 UTC (permalink / raw)
To: John Greene; +Cc: Francois Romieu, David Miller, netdev
In-Reply-To: <50BE4924.40904@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 732 bytes --]
On Tue, 2012-12-04 at 14:04 -0500, John Greene wrote:
> Still, this does fix reported problem that driver could be set to huge
> MTU erroneously, and now rejects really weird values as it should.
Yes, absolutely. As long as the caveat is understood, feel free to add
Tested-by: David Woodhouse <David.Woodhouse@intel.com>
I did look through the datasheet to see if there's anything we can do to
improve reception of large packets. We could try to reduce the Rx Fifo
threshold, which we currently set at 512 bytes... but it isn't going to
get us much further on this particular hardware. Might be nice to have
it tunable though.
There's a v1.6 datasheet at http://realtek.info/pdf/rtl8139cp.pdf btw.
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: doc: add default value for neighbour parameters
From: Ben Hutchings @ 2012-12-06 1:43 UTC (permalink / raw)
To: Shan Wei; +Cc: David Miller, Eric Dumazet, NetDev
In-Reply-To: <50BED29B.4050805@gmail.com>
On Wed, 2012-12-05 at 12:50 +0800, Shan Wei wrote:
> From: Shan Wei <davidshan@tencent.com>
>
> Signed-off-by: Shan Wei <davidshan@tencent.com>
> ---
> Documentation/networking/ip-sysctl.txt | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
> index c6d5fee..0462a71 100644
> --- a/Documentation/networking/ip-sysctl.txt
> +++ b/Documentation/networking/ip-sysctl.txt
> @@ -30,16 +30,24 @@ neigh/default/gc_thresh3 - INTEGER
> Maximum number of neighbor entries allowed. Increase this
> when using large numbers of interfaces and when communicating
> with large numbers of directly-connected peers.
> + Default: 1024
>
> neigh/default/unres_qlen_bytes - INTEGER
> The maximum number of bytes which may be used by packets
> queued for each unresolved address by other network layers.
> (added in linux 3.3)
> + Seting negative value is meaningless and will retrun error.
> + Default: 65536 Bytes(64KB)
>
> neigh/default/unres_qlen - INTEGER
> The maximum number of packets which may be queued for each
> unresolved address by other network layers.
> (deprecated in linux 3.3) : use unres_qlen_bytes instead.
> + Prior to linux 3.3, the default value is 3 which may cause
> + secluded packet loss. The current default value is calculated
^^^^^^^^
I think the proper word here is 'silent'?
> + according to default value of unres_qlen_bytes and true size of
> + packet.
> + Default: 31
>
> mtu_expires - INTEGER
> Time, in seconds, that cached PMTU information is kept.
--
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
* [PATCH net-next] net: fix some compiler warning in net/core/neighbour.c
From: Cong Wang @ 2012-12-06 2:04 UTC (permalink / raw)
To: netdev; +Cc: Shan Wei, David S. Miller, Cong Wang
From: Cong Wang <amwang@redhat.com>
net/core/neighbour.c:65:12: warning: 'zero' defined but not used [-Wunused-variable]
net/core/neighbour.c:66:12: warning: 'unres_qlen_max' defined but not used [-Wunused-variable]
These variables are only used when CONFIG_SYSCTL is defined,
so move them under #ifdef CONFIG_SYSCTL.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Cc: Shan Wei <davidshan@tencent.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 36fc692..c815f28 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -62,9 +62,6 @@ static void __neigh_notify(struct neighbour *n, int type, int flags);
static void neigh_update_notify(struct neighbour *neigh);
static int pneigh_ifdown(struct neigh_table *tbl, struct net_device *dev);
-static int zero;
-static int unres_qlen_max = INT_MAX / SKB_TRUESIZE(ETH_FRAME_LEN);
-
static struct neigh_table *neigh_tables;
#ifdef CONFIG_PROC_FS
static const struct file_operations neigh_stat_seq_fops;
@@ -2772,6 +2769,8 @@ EXPORT_SYMBOL(neigh_app_ns);
#endif /* CONFIG_ARPD */
#ifdef CONFIG_SYSCTL
+static int zero;
+static int unres_qlen_max = INT_MAX / SKB_TRUESIZE(ETH_FRAME_LEN);
static int proc_unres_qlen(ctl_table *ctl, int write, void __user *buffer,
size_t *lenp, loff_t *ppos)
^ permalink raw reply related
* Re: Should we report bus width/speed via ethtool?
From: Ben Hutchings @ 2012-12-06 2:06 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev, e1000-devel list
In-Reply-To: <50BFBE05.7020408@candelatech.com>
On Wed, 2012-12-05 at 13:35 -0800, Ben Greear wrote:
> It seems the only way to get the current pci-e bus speed & width
> in ixgbe (and probably many other NICs) is by parsing output
> of lspci -vvv.
>
> I'd personally find it easier if this info were available via
> ethtool API.
>
> Any opinions on adding this info? I was thinking something like:
[...]
This is nothing specific to network devices, so putting it in ethtool
info is totally inappropriate.
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: WARNING: drivers/net/ethernet/dlink/sundance.o(.text+0x2e87): Section mismatch in reference from the function sundance_probe1() to the variable .devinit.rodata:sundance_pci_tbl
From: Fengguang Wu @ 2012-12-06 2:16 UTC (permalink / raw)
To: David Miller; +Cc: kda, wfp5p, netdev, gregkh
In-Reply-To: <20121205.125006.830180895260845549.davem@davemloft.net>
On Wed, Dec 05, 2012 at 12:50:06PM -0500, David Miller wrote:
> From: Denis Kirjanov <kda@linux-powerpc.org>
> Date: Wed, 5 Dec 2012 11:12:32 +0300
>
> > I"ll fix it.
>
> You can't.
>
> It's only going to get fixed by a change in Greg KH's device tree
> which updates the PCI table macros to not use __dev* section tags.
>
> Fengguant, _PLEASE_, as Greg requested, stop reporting these section
> mismatch errors, they aren't helpful and are wasting valuable
> developer time.
Dave, Greg: Sorry for the delay! I've just disabled these section
mismatch warnings against *devinit*.
Thanks,
Fengguang
^ permalink raw reply
* Re: [net-next 6/8] bna: Add Stats Clear Counter
From: Ben Hutchings @ 2012-12-06 2:19 UTC (permalink / raw)
To: Rasesh Mody; +Cc: davem, netdev, adapter_linux_open_src_team
In-Reply-To: <1354748470-26293-7-git-send-email-rmody@brocade.com>
On Wed, 2012-12-05 at 15:01 -0800, Rasesh Mody wrote:
> Added Stats clear counter to the bfi_enet_stats_mac structure and ethtool stats
>
> Signed-off-by: Rasesh Mody <rmody@brocade.com>
Since this structure appears to be part of the firmware interface, you
should combine this (and any other interface changes) with the change to
the requested firmware version (7/8).
Ben.
> ---
> drivers/net/ethernet/brocade/bna/bfi_enet.h | 1 +
> drivers/net/ethernet/brocade/bna/bnad_ethtool.c | 1 +
> 2 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ethernet/brocade/bna/bfi_enet.h b/drivers/net/ethernet/brocade/bna/bfi_enet.h
> index eef6e1f..7d10e33 100644
> --- a/drivers/net/ethernet/brocade/bna/bfi_enet.h
> +++ b/drivers/net/ethernet/brocade/bna/bfi_enet.h
> @@ -787,6 +787,7 @@ struct bfi_enet_stats_bpc {
>
> /* MAC Rx Statistics */
> struct bfi_enet_stats_mac {
> + u64 stats_clr_cnt; /* times this stats cleared */
> u64 frame_64; /* both rx and tx counter */
> u64 frame_65_127; /* both rx and tx counter */
> u64 frame_128_255; /* both rx and tx counter */
> diff --git a/drivers/net/ethernet/brocade/bna/bnad_ethtool.c b/drivers/net/ethernet/brocade/bna/bnad_ethtool.c
> index 40e1e84..455b5a2 100644
> --- a/drivers/net/ethernet/brocade/bna/bnad_ethtool.c
> +++ b/drivers/net/ethernet/brocade/bna/bnad_ethtool.c
> @@ -102,6 +102,7 @@ static const char *bnad_net_stats_strings[BNAD_ETHTOOL_STATS_NUM] = {
> "rx_unmap_q_alloc_failed",
> "rxbuf_alloc_failed",
>
> + "mac_stats_clr_cnt",
> "mac_frame_64",
> "mac_frame_65_127",
> "mac_frame_128_255",
--
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] net: fix some compiler warning in net/core/neighbour.c
From: Shan Wei @ 2012-12-06 2:39 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, Shan Wei, David S. Miller
In-Reply-To: <1354759444-4937-1-git-send-email-amwang@redhat.com>
Cong Wang said, at 2012/12/6 10:04:
> From: Cong Wang <amwang@redhat.com>
>
> net/core/neighbour.c:65:12: warning: 'zero' defined but not used [-Wunused-variable]
> net/core/neighbour.c:66:12: warning: 'unres_qlen_max' defined but not used [-Wunused-variable]
>
> These variables are only used when CONFIG_SYSCTL is defined,
> so move them under #ifdef CONFIG_SYSCTL.
>
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Cc: Shan Wei <davidshan@tencent.com>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Rapid response~~~ :-)
Same patch in my tree，and i see your patch when prepare to submit it.
Acked-by: Shan Wei <davidshan@tencent.com>
Best Regards
Shan Wei
^ permalink raw reply
* Re: [GIT PULL] Remove __dev* markings from the networking drivers
From: Greg KH @ 2012-12-06 2:48 UTC (permalink / raw)
To: David Miller; +Cc: netdev, wfp5p
In-Reply-To: <20121204.160257.680931337109544105.davem@davemloft.net>
On Tue, Dec 04, 2012 at 04:02:57PM -0500, David Miller wrote:
> From: Greg KH <gregkh@linuxfoundation.org>
> Date: Tue, 4 Dec 2012 12:30:52 -0800
>
> > On Tue, Dec 04, 2012 at 01:17:26PM -0500, David Miller wrote:
> >> It seemse the function declarations were not properly reformatted
> >> after the __dev* tags were removed. You can't just search and replace
> >> this kind of stuff. The result looks terrible.
> >>
> >> Greg please check for things like this next time you send me changes
> >> written by someone else.
> >
> > Ick, sorry about that. Want me to fix them all back up? It's the least
> > I could do.
>
> If you could do that, I'd really appreciate it.
I don't see these patches in your net-next branch yet, so should I just
make this against this branch and do a new pull request? Or am I not
looking at net-next properly?
thanks,
greg k-h
^ permalink raw reply
* Re: [GIT PULL] Remove __dev* markings from the networking drivers
From: David Miller @ 2012-12-06 2:51 UTC (permalink / raw)
To: gregkh; +Cc: netdev, wfp5p
In-Reply-To: <20121206024833.GA8469@kroah.com>
From: Greg KH <gregkh@linuxfoundation.org>
Date: Wed, 5 Dec 2012 18:48:33 -0800
> On Tue, Dec 04, 2012 at 04:02:57PM -0500, David Miller wrote:
>> From: Greg KH <gregkh@linuxfoundation.org>
>> Date: Tue, 4 Dec 2012 12:30:52 -0800
>>
>> > On Tue, Dec 04, 2012 at 01:17:26PM -0500, David Miller wrote:
>> >> It seemse the function declarations were not properly reformatted
>> >> after the __dev* tags were removed. You can't just search and replace
>> >> this kind of stuff. The result looks terrible.
>> >>
>> >> Greg please check for things like this next time you send me changes
>> >> written by someone else.
>> >
>> > Ick, sorry about that. Want me to fix them all back up? It's the least
>> > I could do.
>>
>> If you could do that, I'd really appreciate it.
>
> I don't see these patches in your net-next branch yet, so should I just
> make this against this branch and do a new pull request? Or am I not
> looking at net-next properly?
The drivers/net changes definitely are in my net-next tree. I only use
the 'master' branch.
^ permalink raw reply
* Re: [PATCH net-next] net: fix some compiler warning in net/core/neighbour.c
From: David Miller @ 2012-12-06 2:51 UTC (permalink / raw)
To: shanwei88; +Cc: amwang, netdev, davidshan
In-Reply-To: <50C00544.7060307@gmail.com>
From: Shan Wei <shanwei88@gmail.com>
Date: Thu, 06 Dec 2012 10:39:00 +0800
> Cong Wang said, at 2012/12/6 10:04:
>> From: Cong Wang <amwang@redhat.com>
>>
>> net/core/neighbour.c:65:12: warning: 'zero' defined but not used [-Wunused-variable]
>> net/core/neighbour.c:66:12: warning: 'unres_qlen_max' defined but not used [-Wunused-variable]
>>
>> These variables are only used when CONFIG_SYSCTL is defined,
>> so move them under #ifdef CONFIG_SYSCTL.
>>
>> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
>> Cc: Shan Wei <davidshan@tencent.com>
>> Cc: David S. Miller <davem@davemloft.net>
>> Signed-off-by: Cong Wang <amwang@redhat.com>
>
> Rapid response~~~ :-)
> Same patch in my tree，and i see your patch when prepare to submit it.
>
> Acked-by: Shan Wei <davidshan@tencent.com>
Applied.
^ permalink raw reply
* Re: [GIT PULL] Remove __dev* markings from the networking drivers
From: David Miller @ 2012-12-06 2:52 UTC (permalink / raw)
To: gregkh; +Cc: netdev, wfp5p
In-Reply-To: <20121205.215121.1118396738034568895.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 05 Dec 2012 21:51:21 -0500 (EST)
> From: Greg KH <gregkh@linuxfoundation.org>
> Date: Wed, 5 Dec 2012 18:48:33 -0800
>
>> On Tue, Dec 04, 2012 at 04:02:57PM -0500, David Miller wrote:
>>> From: Greg KH <gregkh@linuxfoundation.org>
>>> Date: Tue, 4 Dec 2012 12:30:52 -0800
>>>
>>> > On Tue, Dec 04, 2012 at 01:17:26PM -0500, David Miller wrote:
>>> >> It seemse the function declarations were not properly reformatted
>>> >> after the __dev* tags were removed. You can't just search and replace
>>> >> this kind of stuff. The result looks terrible.
>>> >>
>>> >> Greg please check for things like this next time you send me changes
>>> >> written by someone else.
>>> >
>>> > Ick, sorry about that. Want me to fix them all back up? It's the least
>>> > I could do.
>>>
>>> If you could do that, I'd really appreciate it.
>>
>> I don't see these patches in your net-next branch yet, so should I just
>> make this against this branch and do a new pull request? Or am I not
>> looking at net-next properly?
>
> The drivers/net changes definitely are in my net-next tree. I only use
> the 'master' branch.
The merge commit is 682d7978aee072f411fc747d32954a8371dd7b1b
^ permalink raw reply
* Re: [GIT PULL] Remove __dev* markings from the networking drivers
From: Greg KH @ 2012-12-06 2:56 UTC (permalink / raw)
To: David Miller; +Cc: netdev, wfp5p
In-Reply-To: <20121205.215246.789211879539058594.davem@davemloft.net>
On Wed, Dec 05, 2012 at 09:52:46PM -0500, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Wed, 05 Dec 2012 21:51:21 -0500 (EST)
>
> > From: Greg KH <gregkh@linuxfoundation.org>
> > Date: Wed, 5 Dec 2012 18:48:33 -0800
> >
> >> On Tue, Dec 04, 2012 at 04:02:57PM -0500, David Miller wrote:
> >>> From: Greg KH <gregkh@linuxfoundation.org>
> >>> Date: Tue, 4 Dec 2012 12:30:52 -0800
> >>>
> >>> > On Tue, Dec 04, 2012 at 01:17:26PM -0500, David Miller wrote:
> >>> >> It seemse the function declarations were not properly reformatted
> >>> >> after the __dev* tags were removed. You can't just search and replace
> >>> >> this kind of stuff. The result looks terrible.
> >>> >>
> >>> >> Greg please check for things like this next time you send me changes
> >>> >> written by someone else.
> >>> >
> >>> > Ick, sorry about that. Want me to fix them all back up? It's the least
> >>> > I could do.
> >>>
> >>> If you could do that, I'd really appreciate it.
> >>
> >> I don't see these patches in your net-next branch yet, so should I just
> >> make this against this branch and do a new pull request? Or am I not
> >> looking at net-next properly?
> >
> > The drivers/net changes definitely are in my net-next tree. I only use
> > the 'master' branch.
>
> The merge commit is 682d7978aee072f411fc747d32954a8371dd7b1b
Ugh, sorry about that, I forgot I had pointed my repo at my copy, not
yours, my fault, you are right. sorry for the noise.
greg "time to knock off for the night, I'm doing stupid mistakes" k-h
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: doc: add default value for neighbour parameters
From: Shan Wei @ 2012-12-06 2:58 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, Eric Dumazet, NetDev
In-Reply-To: <1354758235.17107.131.camel@deadeye.wl.decadent.org.uk>
Ben Hutchings said, at 2012/12/6 9:43:
>> neigh/default/unres_qlen - INTEGER
>> The maximum number of packets which may be queued for each
>> unresolved address by other network layers.
>> (deprecated in linux 3.3) : use unres_qlen_bytes instead.
>> + Prior to linux 3.3, the default value is 3 which may cause
>> + secluded packet loss. The current default value is calculated
> ^^^^^^^^
> I think the proper word here is 'silent'?
The number of lost packets is recorded in unresolved_discards
of /proc/net/stat/arp_cache. Although, arp_cache is not easy
to understand(I still don't know why we need so many rows),
We can confirm dropping event from unresolved_discards in last column.
The dropping event is not marked by absence of sound.
But for general user who using TCP/UDP or ping to sending packets
out, can't simply find the dropping reason that destination ip is unresolved.
They just doubt about the TCP/UDP or ping. So I use 'secluded' which is hidden
from general view.
My English is not good enough, if missing something, please point to me.
Thanks.
Best Regards
Shan Wei
^ permalink raw reply
* Re: [RFC PATCH 1/2] tun: correctly report an error in tun_flow_init()
From: Jason Wang @ 2012-12-06 3:35 UTC (permalink / raw)
To: Paul Moore; +Cc: netdev, linux-security-module, selinux
In-Reply-To: <2057175.PIsargdSHu@sifl>
On Wednesday, December 05, 2012 11:02:04 AM Paul Moore wrote:
> On Thursday, November 29, 2012 05:06:29 PM Paul Moore wrote:
> > On error, the error code from tun_flow_init() is lost inside
> > tun_set_iff(), this patch fixes this by assigning the tun_flow_init()
> > error code to the "err" variable which is returned by
> > the tun_flow_init() function on error.
> >
> > Signed-off-by: Paul Moore <pmoore@redhat.com>
>
> Jason, we've had some good discussion around patch 2/2 but nothing on this
> fix; can I assume you are okay with this patch? If so I think we should go
> ahead and apply this ...
Yes, it looks good. Maybe we can separate this patch from this RFC series and
tag it as "net-next" to let David apply it soon.
Thanks
>
> > ---
> >
> > drivers/net/tun.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > index 607a3a5..877ffe2 100644
> > --- a/drivers/net/tun.c
> > +++ b/drivers/net/tun.c
> > @@ -1605,7 +1605,8 @@ static int tun_set_iff(struct net *net, struct file
> > *file, struct ifreq *ifr)
> >
> > tun_net_init(dev);
> >
> > - if (tun_flow_init(tun))
> > + err = tun_flow_init(tun);
> > + if (err < 0)
> >
> > goto err_free_dev;
> >
> > dev->hw_features = NETIF_F_SG | NETIF_F_FRAGLIST |
^ permalink raw reply
* Re: [PATCH rfc] netfilter: two xtables matches
From: Pablo Neira Ayuso @ 2012-12-06 5:22 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Willem de Bruijn, netfilter-devel, netdev, Eric Dumazet,
David Miller, kaber
In-Reply-To: <alpine.LNX.2.01.1212052100190.30908@nerf07.vanv.qr>
On Wed, Dec 05, 2012 at 09:00:36PM +0100, Jan Engelhardt wrote:
> On Wednesday 2012-12-05 20:28, Willem de Bruijn wrote:
>
> >Somehow, the first part of this email went missing. Not critical,
> >but for completeness:
> >
> >These two patches each add an xtables match.
> >
> >The xt_priority match is a straighforward addition in the style of
> >xt_mark, adding the option to filter on one more sk_buff field. I
> >have an immediate application for this. The amount of code (in
> >kernel + userspace) to add a single check proved quite large.
>
> Hm so yeah, can't we just place this in xt_mark.c?
I don't feel this belongs to xt_mark at all.
^ permalink raw reply
* Re: [PATCH] net: fixup tx time stamping for uml vde driver.
From: Richard Cochran @ 2012-12-06 6:55 UTC (permalink / raw)
To: Paul Chavent; +Cc: jdike, richard, user-mode-linux-devel, netdev
In-Reply-To: <1354717253-8737-1-git-send-email-paul.chavent@onera.fr>
On Wed, Dec 05, 2012 at 03:20:53PM +0100, Paul Chavent wrote:
> Call skb_tx_timestamp after write completion.
>
> Signed-off-by: Paul Chavent <paul.chavent@onera.fr>
The subject line would better describe the changes if it would read,
"enable tx time stamping in the uml vde driver."
Can you please also add support for ethtool get_ts_info?
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH net 1/1] r8169: workaround for missing extended GigaMAC registers
From: Wang YanQing @ 2012-12-06 7:38 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, David Miller, Lee Chun-Yi, Hayes Wang
In-Reply-To: <20121205223452.GA24164@electric-eye.fr.zoreil.com>
On Wed, Dec 05, 2012 at 11:34:52PM +0100, Francois Romieu wrote:
> GigaMAC registers have been reported left unitialized in several
> situations:
> - after cold boot from power-off state
> - after S3 resume
>
> Tweaking rtl_hw_phy_config takes care of both.
Hi Francois.
Are you sure we will lost GigaMAC registers's content
after NIC into PCI_D3hot state?
Thanks
^ permalink raw reply
* Re: [PATCHv5] virtio-spec: virtio network device RFS support
From: Michael S. Tsirkin @ 2012-12-06 8:13 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, kvm, virtualization
In-Reply-To: <1354739966.2655.25.camel@bwh-desktop.uk.solarflarecom.com>
On Wed, Dec 05, 2012 at 08:39:26PM +0000, Ben Hutchings wrote:
> On Mon, 2012-12-03 at 12:58 +0200, Michael S. Tsirkin wrote:
> > Add RFS support to virtio network device.
> > Add a new feature flag VIRTIO_NET_F_RFS for this feature, a new
> > configuration field max_virtqueue_pairs to detect supported number of
> > virtqueues as well as a new command VIRTIO_NET_CTRL_RFS to program
> > packet steering for unidirectional protocols.
> [...]
> > +Programming of the receive flow classificator is implicit.
> > + Transmitting a packet of a specific flow on transmitqX will cause incoming
> > + packets for this flow to be steered to receiveqX.
> > + For uni-directional protocols, or where no packets have been transmitted
> > + yet, device will steer a packet to a random queue out of the specified
> > + receiveq0..receiveqn.
> [...]
>
> It doesn't seem like this is usable to implement accelerated RFS in the
> guest, though perhaps that doesn't matter.
What is the issue? Could you be more explicit please?
It seems to work pretty well: if we have
# of queues >= # of cpus, incoming TCP_STREAM into
guest scales very nicely without manual tweaks in guest.
The way it works is, when guest sends a packet driver
select the rx queue that we want to use for incoming
packets for this slow, and transmit on the matching tx queue.
This is exactly what text above suggests no?
> On the host side, presumably
> you'll want vhost_net to do the equivalent of sock_rps_record_flow() -
> only without a socket? But in any case, that requires an rxhash, so I
> don't see how this is supposed to work.
>
> Ben.
Host should just do what guest tells it to.
On the host side we build up the steering table as we get packets
to transmit. See the code in drivers/net/tun.c in recent
kernels.
Again this actually works fine - what are the problems that you see?
Could you give an example please?
> --
> 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 0/7] Allow to monitor multicast cache event via rtnetlink
From: Nicolas Dichtel @ 2012-12-06 8:43 UTC (permalink / raw)
To: David Miller; +Cc: David.Laight, netdev
In-Reply-To: <20121205.125453.1457654258131828976.davem@davemloft.net>
Le 05/12/2012 18:54, David Miller a écrit :
> From: "David Laight" <David.Laight@ACULAB.COM>
> Date: Wed, 5 Dec 2012 11:41:33 -0000
>
>> Probably worth commenting that the 64bit items might only be 32bit aligned.
>> Just to stop anyone trying to read/write them with pointer casts.
>
> Rather, let's not create this situation at all.
>
> It's totally inappropriate to have special code to handle every single
> time we want to put 64-bit values into netlink messages.
>
> We need a real solution to this issue.
>
The easiest way is to update *_ALIGNTO values (maybe we can keep NLMSG_ALIGNTO
to 4). But I think that many userland apps have these values hardcoded and, the
most important thing, this may increase size of many netlink messages. Hence we
need probably to find something better.
diff --git a/include/uapi/linux/netfilter/nfnetlink_compat.h
b/include/uapi/linux/netfilter/nfnetlink_compat.h
index ffb9503..121e62a 100644
--- a/include/uapi/linux/netfilter/nfnetlink_compat.h
+++ b/include/uapi/linux/netfilter/nfnetlink_compat.h
@@ -33,7 +33,7 @@ struct nfattr {
#define NFNL_NFA_NEST 0x8000
#define NFA_TYPE(attr) ((attr)->nfa_type & 0x7fff)
-#define NFA_ALIGNTO 4
+#define NFA_ALIGNTO 8
#define NFA_ALIGN(len) (((len) + NFA_ALIGNTO - 1) & ~(NFA_ALIGNTO - 1))
#define NFA_OK(nfa,len) ((len) > 0 && (nfa)->nfa_len >= sizeof(struct nfattr) \
&& (nfa)->nfa_len <= (len))
diff --git a/include/uapi/linux/netlink.h b/include/uapi/linux/netlink.h
index 78d5b8a..66d2a26 100644
--- a/include/uapi/linux/netlink.h
+++ b/include/uapi/linux/netlink.h
@@ -75,7 +75,7 @@ struct nlmsghdr {
Check NLM_F_EXCL
*/
-#define NLMSG_ALIGNTO 4U
+#define NLMSG_ALIGNTO 8U
#define NLMSG_ALIGN(len) ( ((len)+NLMSG_ALIGNTO-1) & ~(NLMSG_ALIGNTO-1) )
#define NLMSG_HDRLEN ((int) NLMSG_ALIGN(sizeof(struct nlmsghdr)))
#define NLMSG_LENGTH(len) ((len)+NLMSG_ALIGN(NLMSG_HDRLEN))
@@ -145,7 +145,7 @@ struct nlattr {
#define NLA_F_NET_BYTEORDER (1 << 14)
#define NLA_TYPE_MASK ~(NLA_F_NESTED | NLA_F_NET_BYTEORDER)
-#define NLA_ALIGNTO 4
+#define NLA_ALIGNTO 8
#define NLA_ALIGN(len) (((len) + NLA_ALIGNTO - 1) & ~(NLA_ALIGNTO - 1))
#define NLA_HDRLEN ((int) NLA_ALIGN(sizeof(struct nlattr)))
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index 33d29ce..ee898c1 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -146,7 +146,7 @@ struct rtattr {
/* Macros to handle rtattributes */
-#define RTA_ALIGNTO 4
+#define RTA_ALIGNTO 8
#define RTA_ALIGN(len) ( ((len)+RTA_ALIGNTO-1) & ~(RTA_ALIGNTO-1) )
#define RTA_OK(rta,len) ((len) >= (int)sizeof(struct rtattr) && \
(rta)->rta_len >= sizeof(struct rtattr) && \
@@ -322,7 +322,7 @@ struct rtnexthop {
/* Macros to handle hexthops */
-#define RTNH_ALIGNTO 4
+#define RTNH_ALIGNTO 8
#define RTNH_ALIGN(len) ( ((len)+RTNH_ALIGNTO-1) & ~(RTNH_ALIGNTO-1) )
#define RTNH_OK(rtnh,len) ((rtnh)->rtnh_len >= sizeof(struct rtnexthop) && \
((int)(rtnh)->rtnh_len) <= (len))
^ 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