* Re: [PATCH] lpc_eth: remove duplicated include
From: David Miller @ 2012-07-16 9:58 UTC (permalink / raw)
To: djduanjiong; +Cc: netdev
In-Reply-To: <5003E362.4060604@gmail.com>
Without a proper signoff, I will not apply your patch.
^ permalink raw reply
* Re: iptables CLAMP MSS to PMTU not working?
From: Steffen Klassert @ 2012-07-16 10:08 UTC (permalink / raw)
To: Timo Teras; +Cc: David S. Miller, netdev
In-Reply-To: <20120716105546.14a6490d@vostro>
On Mon, Jul 16, 2012 at 10:55:46AM +0300, Timo Teras wrote:
> On Mon, 16 Jul 2012 09:23:05 +0200 Steffen Klassert
> <steffen.klassert@secunet.com> wrote:
> >
> > I did this patch to avoid to propagate learned PMTU informations.
> > It restores the behaviour we had before we moved the PMTU informations
> > to the inetpeer. Unfortunately CLAMPMSS really wants to have the PMTU
> > informations of an input route, which is not possible any more after
> > this patch.
> >
> > Anyway, this patch seems to be obsolete in the net-next tree, as
> > the cached pmtu informations are back in the route. So we should
> > remove the check for an output route from ipv4_mtu() in the net-next
> > tree. This should bring CLAMPMSS back to work, at least for upcoming
> > kernel versions.
>
> Right, saw those commits. But before net-next hits release, I'd really
> need a fix for 3.3/3.4/3.5. Non-working fragmentation with IPsec, and
> this CLAMPMSS thingy are an upgrade stopper for me.
>
> Would it be safe to just revert this commit, with the side-effect of
> exposing cached pmtu too agressively?
The router that can't send the packet to the next hop network has to
send the ICMP Destination Unreachable message. We never propagated
learned PMTU informations and I would not like to change this, in
particular not in a stable kernel.
Maybe we could fix this for already released kernels within the
netfilter module. Perhaps we could add a function
static unsigned int tcpmss_mtu(const struct dst_entry *dst)
{
unsigned int mtu = dst_metric_raw(dst, RTAX_MTU);
return mtu ? : dst_mtu(dst->path);
}
and use this instead of dst_mtu().
>
> Or would it be better to try to backport the relevant changes of moving
> pmtu back to route table?
A backport is probaply too invasive for a stable kernel.
^ permalink raw reply
* Re: [PATCH net-next 0/8] etherdevice: Rename random_ether_addr to eth_random_addr
From: Felipe Balbi @ 2012-07-16 10:14 UTC (permalink / raw)
To: Joe Perches
Cc: David Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, wimax-BPSAo7wm5JOHVYUYWc+uSQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
users-poMEt7QlJxcwIE2E9O76wjtx2kNaKg5H,
linux-s390-u79uwXL29TY76Z2rM5mHXA, Johannes Berg,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-c6x-dev-jPsnJVOj+W6hPH1hqNUYSQ,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
user-mode-linux-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
user-mode-linux-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
e1000-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <cover.1342157022.git.joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3693 bytes --]
On Thu, Jul 12, 2012 at 10:33:04PM -0700, Joe Perches wrote:
> net-next commit ad7eee98be ("etherdevice: introduce eth_broadcast_addr")
> added a new style API. Rename random_ether_addr to eth_random_addr to
> create some API symmetry.
>
> Joe Perches (8):
> etherdevice: Rename random_ether_addr to eth_random_addr
if you're really renaming the function, then this patch alone will break
all of the below users. That should all be a single patch, I'm afraid.
> ethernet: Use eth_random_addr
> net: usb: Use eth_random_addr
> wireless: Use eth_random_addr
> drivers/net: Use eth_random_addr
> s390: Use eth_random_addr
> usb: Use eth_random_addr
> arch: Use eth_random_addr
>
> arch/blackfin/mach-bf537/boards/stamp.c | 2 +-
> arch/c6x/kernel/soc.c | 2 +-
> arch/mips/ar7/platform.c | 4 ++--
> arch/mips/powertv/powertv_setup.c | 6 +++---
> arch/um/drivers/net_kern.c | 2 +-
> drivers/net/ethernet/atheros/atl1c/atl1c_hw.c | 2 +-
> drivers/net/ethernet/atheros/atlx/atl1.c | 2 +-
> drivers/net/ethernet/atheros/atlx/atl2.c | 2 +-
> drivers/net/ethernet/ethoc.c | 2 +-
> drivers/net/ethernet/intel/igb/igb_main.c | 4 ++--
> drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 2 +-
> drivers/net/ethernet/lantiq_etop.c | 2 +-
> drivers/net/ethernet/micrel/ks8851.c | 2 +-
> drivers/net/ethernet/micrel/ks8851_mll.c | 2 +-
> drivers/net/ethernet/smsc/smsc911x.c | 2 +-
> drivers/net/ethernet/ti/cpsw.c | 2 +-
> drivers/net/ethernet/tile/tilegx.c | 2 +-
> drivers/net/ethernet/wiznet/w5100.c | 2 +-
> drivers/net/ethernet/wiznet/w5300.c | 2 +-
> drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 2 +-
> drivers/net/tun.c | 2 +-
> drivers/net/usb/smsc75xx.c | 2 +-
> drivers/net/usb/smsc95xx.c | 2 +-
> drivers/net/usb/usbnet.c | 2 +-
> drivers/net/wimax/i2400m/driver.c | 2 +-
> drivers/net/wireless/adm8211.c | 2 +-
> drivers/net/wireless/p54/eeprom.c | 2 +-
> drivers/net/wireless/rt2x00/rt2400pci.c | 2 +-
> drivers/net/wireless/rt2x00/rt2500pci.c | 2 +-
> drivers/net/wireless/rt2x00/rt2500usb.c | 2 +-
> drivers/net/wireless/rt2x00/rt2800lib.c | 2 +-
> drivers/net/wireless/rt2x00/rt61pci.c | 2 +-
> drivers/net/wireless/rt2x00/rt73usb.c | 2 +-
> drivers/net/wireless/rtl818x/rtl8180/dev.c | 2 +-
> drivers/net/wireless/rtl818x/rtl8187/dev.c | 2 +-
> drivers/s390/net/qeth_l2_main.c | 2 +-
> drivers/s390/net/qeth_l3_main.c | 2 +-
> drivers/usb/atm/xusbatm.c | 4 ++--
> drivers/usb/gadget/u_ether.c | 2 +-
> include/linux/etherdevice.h | 14 ++++++++------
> 40 files changed, 52 insertions(+), 50 deletions(-)
>
> --
> 1.7.8.111.gad25c.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 0/8] etherdevice: Rename random_ether_addr to eth_random_addr
From: David Miller @ 2012-07-16 10:29 UTC (permalink / raw)
To: balbi
Cc: linux-s390, linux-c6x-dev, wimax, linux-mips,
user-mode-linux-user, netdev, linux-usb, linux-wireless, users,
linux-kernel, e1000-devel, user-mode-linux-devel, joe,
uclinux-dist-devel, johannes
In-Reply-To: <20120716101437.GC22638@arwen.pp.htv.fi>
From: Felipe Balbi <balbi@ti.com>
Date: Mon, 16 Jul 2012 13:14:38 +0300
> if you're really renaming the function, then this patch alone will break
> all of the below users. That should all be a single patch, I'm afraid.
It would help if you actually read his patches before saying what they
might or might not do.
He provides a macro in the first patch that provides the old name,
and this will get removed at the end.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: iptables CLAMP MSS to PMTU not working?
From: Timo Teras @ 2012-07-16 10:53 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David S. Miller, netdev
In-Reply-To: <20120716100844.GK1869@secunet.com>
On Mon, 16 Jul 2012 12:08:44 +0200 Steffen Klassert
<steffen.klassert@secunet.com> wrote:
> On Mon, Jul 16, 2012 at 10:55:46AM +0300, Timo Teras wrote:
> > On Mon, 16 Jul 2012 09:23:05 +0200 Steffen Klassert
> > <steffen.klassert@secunet.com> wrote:
> > >
> > > I did this patch to avoid to propagate learned PMTU informations.
> > > It restores the behaviour we had before we moved the PMTU
> > > informations to the inetpeer. Unfortunately CLAMPMSS really wants
> > > to have the PMTU informations of an input route, which is not
> > > possible any more after this patch.
> > >
> > > Anyway, this patch seems to be obsolete in the net-next tree, as
> > > the cached pmtu informations are back in the route. So we should
> > > remove the check for an output route from ipv4_mtu() in the
> > > net-next tree. This should bring CLAMPMSS back to work, at least
> > > for upcoming kernel versions.
> >
> > Right, saw those commits. But before net-next hits release, I'd
> > really need a fix for 3.3/3.4/3.5. Non-working fragmentation with
> > IPsec, and this CLAMPMSS thingy are an upgrade stopper for me.
> >
> > Would it be safe to just revert this commit, with the side-effect of
> > exposing cached pmtu too agressively?
>
> The router that can't send the packet to the next hop network has to
> send the ICMP Destination Unreachable message. We never propagated
> learned PMTU informations and I would not like to change this, in
> particular not in a stable kernel.
Ah, now I understand what you mean with "propagation". Leaking out the
PMTU of locally originating traffic to the forward path.
Makes sense. I'll probably just revert the change locally, as for my
use this should not be a problem.
> Maybe we could fix this for already released kernels within the
> netfilter module. Perhaps we could add a function
>
> static unsigned int tcpmss_mtu(const struct dst_entry *dst)
> {
> unsigned int mtu = dst_metric_raw(dst, RTAX_MTU);
>
> return mtu ? : dst_mtu(dst->path);
> }
>
> and use this instead of dst_mtu().
Yes, of course this fixes TCPMSS; but not IPsec fragmentation which is
even more critical.
On forward path, if I send large IP-packets (e.g. ping -s 1500) with
DF-bit not set to a destination that is XFRMed, I get now blackholed.
This is because the large packet is fragmented according to the forward
route MTU which now does not account the XFRM headers and the fragments
are too large to be sent out. This causes the packets to get dropped
to floor; and since DF was not set, there's no ICMP error sent out.
With fragmentation the originator is not and does not want to be aware
of the PMTU.
Basically the MTU needs to be accurate for fragmentation to work.
Just using the "device MTU" or "route MTU" is not enough. This is
because XFRMed target MTU is currently learned dynamically. The
per-packet overhead can depend on destination IP (e.g. per-IP SA can
have different hash or encapsulation which affects the header size and
thus the overall MTU).
I guess it would be better if the XFRMed MTUs were calculated properly.
This would avoid one lost packet -- the one that gets sent out using
the device/route MTU, then triggers route pmtu to get updated, and
dropped. Then further packets get fragmented according to the cached
pmtu properly. Would be nice if this "learning" packet was not needed.
^ permalink raw reply
* MY ASSISTANCE TO PAY YOUR ACCRUED INTEREST AMOUNT. PLEASE OPEN THE FILE FOR MORE DETAILS
From: MR. CHRIS @ 2012-07-16 10:36 UTC (permalink / raw)
To: Recipients
[-- Attachment #1: Mail message body --]
[-- Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: FROM MR. CHRIS.rtf --]
[-- Type: application/octet-stream, Size: 5642 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 0/8] etherdevice: Rename random_ether_addr to eth_random_addr
From: Felipe Balbi @ 2012-07-16 11:12 UTC (permalink / raw)
To: David Miller
Cc: balbi, joe, netdev, linux-usb, wimax, linux-wireless, users,
linux-s390, johannes, uclinux-dist-devel, linux-kernel,
linux-c6x-dev, linux-mips, user-mode-linux-devel,
user-mode-linux-user, e1000-devel
In-Reply-To: <20120716.032901.1657058688119342783.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 788 bytes --]
Hi,
On Mon, Jul 16, 2012 at 03:29:01AM -0700, David Miller wrote:
> From: Felipe Balbi <balbi@ti.com>
> Date: Mon, 16 Jul 2012 13:14:38 +0300
>
> > if you're really renaming the function, then this patch alone will break
> > all of the below users. That should all be a single patch, I'm afraid.
>
> It would help if you actually read his patches before saying what they
> might or might not do.
>
> He provides a macro in the first patch that provides the old name,
> and this will get removed at the end.
that's why I put an "if" there. The subject was misleading and I really
couldn't bother going search for the patch on the mail archives.
Anyway, if nothing will be broken then for drivers/usb/gadget/:
Acked-by: Felipe Balbi <balbi@ti.com>
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] net: respect GFP_DMA in __netdev_alloc_skb()
From: Eric Dumazet @ 2012-07-16 11:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
Few drivers use GFP_DMA allocations, and netdev_alloc_frag()
doesn't allocate pages in DMA zone.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/core/skbuff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 46a3d23..d124306 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -353,7 +353,7 @@ struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
unsigned int fragsz = SKB_DATA_ALIGN(length + NET_SKB_PAD) +
SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
- if (fragsz <= PAGE_SIZE && !(gfp_mask & __GFP_WAIT)) {
+ if (fragsz <= PAGE_SIZE && !(gfp_mask & (__GFP_WAIT | GFP_DMA))) {
void *data = netdev_alloc_frag(fragsz);
if (likely(data)) {
^ permalink raw reply related
* Re: [PATCH net-next 0/8] etherdevice: Rename random_ether_addr to eth_random_addr
From: David Miller @ 2012-07-16 11:17 UTC (permalink / raw)
To: balbi-l0cyMroinI0
Cc: joe-6d6DIl74uiNBDgjK7y7TUQ, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, wimax-BPSAo7wm5JOHVYUYWc+uSQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
users-poMEt7QlJxcwIE2E9O76wjtx2kNaKg5H,
linux-s390-u79uwXL29TY76Z2rM5mHXA,
johannes-cdvu00un1VgdHxzADdlk8Q,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-c6x-dev-jPsnJVOj+W6hPH1hqNUYSQ,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
user-mode-linux-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
user-mode-linux-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
e1000-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20120716111218.GA4913-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
From: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
Date: Mon, 16 Jul 2012 14:12:19 +0300
> Acked-by: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
You need to provide this in a reply to the patch you actually want
to ACK, so that the patch tracking system attaches your ACK to
the proper patch.
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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] net: respect GFP_DMA in __netdev_alloc_skb()
From: David Miller @ 2012-07-16 11:18 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1342437352.23494.8.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 16 Jul 2012 13:15:52 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Few drivers use GFP_DMA allocations, and netdev_alloc_frag()
> doesn't allocate pages in DMA zone.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: resurrecting tcphealth
From: Piotr Sawuk @ 2012-07-16 11:33 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20120713165544.6767ea8f@nehalam.linuxnetplumber.net>
On Sa, 14.07.2012, 01:55, Stephen Hemminger wrote:
> I am not sure if the is really necessary since the most
> of the stats are available elsewhere.
if by "most" you mean address and port then you're right.
but even the rtt reported by "ss -i" seems to differ from tcphealth.
however, if instead by "elsewhere" you mean "on the server"...
>
>>+ seq_printf(seq,
>>+ "TCP Health Monitoring (established connections only)\n"
>>+ " -Duplicate ACKs indicate lost or reordered packets on the
>>connection.\n"
>>+ " -Duplicate Packets Received signal a slow and badly inefficient
>>connection.\n"
>>+ " -RttEst estimates how long future packets will take on a round trip
>>over the connection.\n"
>>+ "id Local Address Remote Address RttEst(ms) AcksSent "
>
> Header seems excessive, just put one line of header please.
I guess the header was sort of documentation for this patch.
I've put it into Kconfig instead.
>
>
>>+ "DupAcksSent PktsRecv DupPktsRecv\n");
>>+ goto out;
>>+ }
>>+
>>+ /* Loop through established TCP connections */
>>+ st = seq->private;
>>+
>>+
>>+ if (st->state == TCP_SEQ_STATE_ESTABLISHED)
>>+ {
>>+/* ; //insert read-lock here */
>
> Don't think you need read-lock
you mean I wont get segfault reading a tcp_sock that's gone?
>
> Kernel has %pI4 to print IP addresses.
thanks, I didn't know.
>
>>+ seq_printf(seq, "%*s\n", LINESZ - 1 - len, "");
>
> This padding of line is bogus, just print variable length line.
> Are you trying to make it fixed length record file?
I guess so, /proc/net/tcp is doing the same.
wont question the authors of that user-interface.
OK, new version, this time with Kconfig changed:
diff -rub A/include/linux/tcp.h B/include/linux/tcp.h
--- A/include/linux/tcp.h 2012-07-08 02:23:56.000000000 +0200
+++ B/include/linux/tcp.h 2012-07-16 09:04:54.000000000 +0200
@@ -492,6 +492,17 @@
* contains related tcp_cookie_transactions fields.
*/
struct tcp_cookie_values *cookie_values;
+
+#ifdef CONFIG_TCPHEALTH
+ /*
+ * TCP health monitoring counters.
+ */
+ __u32 dup_acks_sent;
+ __u32 dup_pkts_recv;
+ __u32 acks_sent;
+ __u32 pkts_recv;
+ __u32 last_ack_sent; /* Sequence number of the last ack we sent. */
+#endif
};
static inline struct tcp_sock *tcp_sk(const struct sock *sk)
Only in B/include/linux: tcp.h.orig
diff -rub A/net/ipv4/Kconfig B/net/ipv4/Kconfig
--- A/net/ipv4/Kconfig 2012-07-08 02:23:56.000000000 +0200
+++ B/net/ipv4/Kconfig 2012-07-16 11:56:15.000000000 +0200
@@ -619,6 +619,28 @@
default "reno" if DEFAULT_RENO
default "cubic"
+config TCPHEALTH
+ bool "TCP: client-side health-statistics (/proc/net/tcphealth)"
+ default n
+ ---help---
+ IPv4 TCP Health Monitoring (established connections only):
+ -Duplicate ACKs indicate there could be lost or reordered packets
+ on the connection.
+ -Duplicate Packets Received signal a slow and badly inefficient
+ connection.
+ -RttEst estimates how long future packets will take on a round trip
+ over the connection.
+
+ Additionally you get total amount of sent ACKs and received Packets.
+ All these values are displayed seperately for each connection.
+ If you are running a dedicated server you wont need this.
+ Duplicate ACKs refers only to those sent upon receiving a Packet.
+ A server most likely doesn't receive much Packets to count.
+ Hence for a server these statistics wont be meaningful.
+ especially since they are split into individual connections.
+
+ If you plan to investigate why some download is slow, say Y.
+
config TCP_MD5SIG
bool "TCP: MD5 Signature Option support (RFC2385) (EXPERIMENTAL)"
depends on EXPERIMENTAL
Only in B/net/ipv4: Kconfig~
diff -rub A/net/ipv4/tcp_input.c B/net/ipv4/tcp_input.c
--- A/net/ipv4/tcp_input.c 2012-07-08 02:23:56.000000000 +0200
+++ B/net/ipv4/tcp_input.c 2012-07-16 09:28:23.000000000 +0200
@@ -4492,6 +4492,11 @@
}
if (!after(TCP_SKB_CB(skb)->end_seq, tp->rcv_nxt)) {
+#ifdef CONFIG_TCPHEALTH
+ /* Course Timeout caused retransmit inefficiency-
+ * this packet has been received twice. */
+ tp->dup_pkts_recv++;
+#endif
SOCK_DEBUG(sk, "ofo packet was already received\n");
__skb_unlink(skb, &tp->out_of_order_queue);
__kfree_skb(skb);
@@ -4824,6 +4829,12 @@
return;
}
+#ifdef CONFIG_TCPHEALTH
+ /* A packet is a "duplicate" if it contains bytes we have already
received. */
+ if (before(TCP_SKB_CB(skb)->seq, tp->rcv_nxt))
+ tp->dup_pkts_recv++;
+#endif
+
if (!after(TCP_SKB_CB(skb)->end_seq, tp->rcv_nxt)) {
/* A retransmit, 2nd most common case. Force an immediate ack. */
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_DELAYEDACKLOST);
@@ -5535,6 +5546,12 @@
tp->rx_opt.saw_tstamp = 0;
+#ifdef CONFIG_TCPHEALTH
+ /*
+ * total per-connection packet arrivals.
+ */
+ tp->pkts_recv++;
+#endif
/* pred_flags is 0xS?10 << 16 + snd_wnd
* if header_prediction is to be made
* 'S' will always be tp->tcp_header_len >> 2
diff -rub A/net/ipv4/tcp_ipv4.c B/net/ipv4/tcp_ipv4.c
--- A/net/ipv4/tcp_ipv4.c 2012-07-08 02:23:56.000000000 +0200
+++ B/net/ipv4/tcp_ipv4.c 2012-07-16 10:12:48.000000000 +0200
@@ -2500,6 +2500,57 @@
return 0;
}
+#ifdef CONFIG_TCPHEALTH
+/*
+ * Output /proc/net/tcphealth
+ */
+#define LINESZ 128
+
+int tcp_health_seq_show(struct seq_file *seq, void *v)
+{
+ int len, num;
+ struct tcp_iter_state *st;
+
+ if (v == SEQ_START_TOKEN) {
+ seq_printf(seq,
+ "id Local Address Remote Address RttEst(ms) AcksSent "
+ "DupAcksSent PktsRecv DupPktsRecv\n");
+ goto out;
+ }
+
+ /* Loop through established TCP connections */
+ st = seq->private;
+
+
+ if (st->state == TCP_SEQ_STATE_ESTABLISHED)
+ {
+ const struct tcp_sock *tp = tcp_sk(v);
+ const struct inet_sock *inet = inet_sk(v);
+
+ seq_printf(seq, "%d: %-21pI4:%u %-21pI4:%u "
+ "%8lu %8lu %8lu %8lu %8lu%n",
+ st->num,
+ inet->inet_rcv_saddr,
+ ntohs(inet->inet_sport),
+ inet->inet_daddr,
+ ntohs(inet->inet_dport),
+ tp->srtt >> 3,
+ tp->acks_sent,
+ tp->dup_acks_sent,
+ tp->pkts_recv,
+ tp->dup_pkts_recv,
+
+ &len
+ );
+
+ seq_printf(seq, "%*s\n", LINESZ - 1 - len, "");
+ }
+
+out:
+ return 0;
+}
+#endif /* CONFIG_TCPHEALTH */
+
static const struct file_operations tcp_afinfo_seq_fops = {
.owner = THIS_MODULE,
.open = tcp_seq_open,
@@ -2508,6 +2559,17 @@
.release = seq_release_net
};
+#ifdef CONFIG_TCPHEALTH
+static struct tcp_seq_afinfo tcphealth_seq_afinfo = {
+ .name = "tcphealth",
+ .family = AF_INET,
+ .seq_fops = &tcp_afinfo_seq_fops,
+ .seq_ops = {
+ .show = tcp_health_seq_show,
+ },
+};
+#endif
+
static struct tcp_seq_afinfo tcp4_seq_afinfo = {
.name = "tcp",
.family = AF_INET,
@@ -2519,12 +2581,20 @@
static int __net_init tcp4_proc_init_net(struct net *net)
{
- return tcp_proc_register(net, &tcp4_seq_afinfo);
+ int ret = tcp_proc_register(net, &tcp4_seq_afinfo);
+#ifdef CONFIG_TCPHEALTH
+ if(ret == 0)
+ ret = tcp_proc_register(net, &tcphealth_seq_afinfo);
+#endif
+ return ret;
}
static void __net_exit tcp4_proc_exit_net(struct net *net)
{
tcp_proc_unregister(net, &tcp4_seq_afinfo);
+#ifdef CONFIG_TCPHEALTH
+ tcp_proc_unregister(net, &tcphealth_seq_afinfo);
+#endif
}
static struct pernet_operations tcp4_net_ops = {
Only in B/net/ipv4: tcp_ipv4.c~
Only in B/net/ipv4: tcp_ipv4.c.orig
diff -rub A/net/ipv4/tcp_output.c B/net/ipv4/tcp_output.c
--- A/net/ipv4/tcp_output.c 2012-07-08 02:23:56.000000000 +0200
+++ B/net/ipv4/tcp_output.c 2012-07-16 09:44:02.000000000 +0200
@@ -2772,8 +2772,19 @@
skb_reserve(buff, MAX_TCP_HEADER);
tcp_init_nondata_skb(buff, tcp_acceptable_seq(sk), TCPHDR_ACK);
+#ifdef CONFIG_TCPHEALTH
+ /* If the rcv_nxt has not advanced since sending our last ACK, this is a
duplicate. */
+ if (tcp_sk(sk)->rcv_nxt == tcp_sk(sk)->last_ack_sent)
+ tcp_sk(sk)->dup_acks_sent++;
+ /* Record the total number of acks sent on this connection. */
+ tcp_sk(sk)->acks_sent++;
+#endif
+
/* Send it off, this clears delayed acks for us. */
TCP_SKB_CB(buff)->when = tcp_time_stamp;
+#ifdef CONFIG_TCPHEALTH
+ tcp_sk(sk)->last_ack_sent = tcp_sk(sk)->rcv_nxt;
+#endif
tcp_transmit_skb(sk, buff, 0, GFP_ATOMIC);
}
^ permalink raw reply
* [PATCH net-next] tcp: add OFO snmp counters
From: Eric Dumazet @ 2012-07-16 11:41 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
Add three SNMP TCP counters, to better track TCP behavior
at global stage (netstat -s), when packets are received
Out Of Order (OFO)
TCPOFOQueue : Number of packets queued in OFO queue
TCPOFODrop : Number of packets meant to be queued in OFO
but dropped because socket rcvbuf limit hit.
TCPOFOMerge : Number of packets in OFO that were merged with
other packets.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/linux/snmp.h | 5 ++++-
net/ipv4/proc.c | 3 +++
net/ipv4/tcp_input.c | 7 +++++--
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/include/linux/snmp.h b/include/linux/snmp.h
index 2e68f5b..6e4c511 100644
--- a/include/linux/snmp.h
+++ b/include/linux/snmp.h
@@ -233,7 +233,10 @@ enum
LINUX_MIB_TCPREQQFULLDOCOOKIES, /* TCPReqQFullDoCookies */
LINUX_MIB_TCPREQQFULLDROP, /* TCPReqQFullDrop */
LINUX_MIB_TCPRETRANSFAIL, /* TCPRetransFail */
- LINUX_MIB_TCPRCVCOALESCE, /* TCPRcvCoalesce */
+ LINUX_MIB_TCPRCVCOALESCE, /* TCPRcvCoalesce */
+ LINUX_MIB_TCPOFOQUEUE, /* TCPOFOQueue */
+ LINUX_MIB_TCPOFODROP, /* TCPOFODrop */
+ LINUX_MIB_TCPOFOMERGE, /* TCPOFOMerge */
__LINUX_MIB_MAX
};
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 8af0d44..dae25e76 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -258,6 +258,9 @@ static const struct snmp_mib snmp4_net_list[] = {
SNMP_MIB_ITEM("TCPReqQFullDrop", LINUX_MIB_TCPREQQFULLDROP),
SNMP_MIB_ITEM("TCPRetransFail", LINUX_MIB_TCPRETRANSFAIL),
SNMP_MIB_ITEM("TCPRcvCoalesce", LINUX_MIB_TCPRCVCOALESCE),
+ SNMP_MIB_ITEM("TCPOFOQueue", LINUX_MIB_TCPOFOQUEUE),
+ SNMP_MIB_ITEM("TCPOFODrop", LINUX_MIB_TCPOFODROP),
+ SNMP_MIB_ITEM("TCPOFOMerge", LINUX_MIB_TCPOFOMERGE),
SNMP_MIB_SENTINEL
};
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 055ac49..cc4e12f 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4397,8 +4397,8 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
TCP_ECN_check_ce(tp, skb);
- if (tcp_try_rmem_schedule(sk, skb->truesize)) {
- /* TODO: should increment a counter */
+ if (unlikely(tcp_try_rmem_schedule(sk, skb->truesize))) {
+ NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPOFODROP);
__kfree_skb(skb);
return;
}
@@ -4407,6 +4407,7 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
tp->pred_flags = 0;
inet_csk_schedule_ack(sk);
+ NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPOFOQUEUE);
SOCK_DEBUG(sk, "out of order segment: rcv_next %X seq %X - %X\n",
tp->rcv_nxt, TCP_SKB_CB(skb)->seq, TCP_SKB_CB(skb)->end_seq);
@@ -4460,6 +4461,7 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
if (skb1 && before(seq, TCP_SKB_CB(skb1)->end_seq)) {
if (!after(end_seq, TCP_SKB_CB(skb1)->end_seq)) {
/* All the bits are present. Drop. */
+ NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPOFOMERGE);
__kfree_skb(skb);
skb = NULL;
tcp_dsack_set(sk, seq, end_seq);
@@ -4498,6 +4500,7 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
__skb_unlink(skb1, &tp->out_of_order_queue);
tcp_dsack_extend(sk, TCP_SKB_CB(skb1)->seq,
TCP_SKB_CB(skb1)->end_seq);
+ NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPOFOMERGE);
__kfree_skb(skb1);
}
^ permalink raw reply related
* Re: resurrecting tcphealth
From: Eric Dumazet @ 2012-07-16 11:46 UTC (permalink / raw)
To: Piotr Sawuk; +Cc: netdev, linux-kernel
In-Reply-To: <87741204cd72d363d54dadf9a94bb6fe.squirrel@webmail.univie.ac.at>
On Mon, 2012-07-16 at 13:33 +0200, Piotr Sawuk wrote:
> On Sa, 14.07.2012, 01:55, Stephen Hemminger wrote:
> > I am not sure if the is really necessary since the most
> > of the stats are available elsewhere.
>
> if by "most" you mean address and port then you're right.
> but even the rtt reported by "ss -i" seems to differ from tcphealth.
Thats because tcphealth is wrong, it assumes HZ=1000 ?
tp->srtt unit is jiffies, not ms.
tcphealth is a gross hack.
^ permalink raw reply
* [PATCH] net-next: make sock diag per-namespace
From: Andrew Vagin @ 2012-07-16 12:14 UTC (permalink / raw)
To: David S. Miller
Cc: Andrew Vagin, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Pavel Emelyanov, linux-kernel,
netdev
Before this patch sock_diag works for init_net only and dumps
information about sockets from all namespaces.
This patch expands sock_diag for all name-spaces.
It creates a netlink kernel socket for each netns and filters
data during dumping.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Pavel Emelyanov <xemul@parallels.com>
Cc: linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Andrew Vagin <avagin@openvz.org>
---
include/linux/sock_diag.h | 1 -
include/net/net_namespace.h | 1 +
net/core/sock_diag.c | 28 ++++++++++++++++++++++------
net/ipv4/inet_diag.c | 13 ++++++++++---
net/ipv4/udp_diag.c | 3 ++-
net/unix/diag.c | 9 +++++++--
6 files changed, 42 insertions(+), 13 deletions(-)
diff --git a/include/linux/sock_diag.h b/include/linux/sock_diag.h
index 6793fac..e3e395a 100644
--- a/include/linux/sock_diag.h
+++ b/include/linux/sock_diag.h
@@ -44,6 +44,5 @@ void sock_diag_save_cookie(void *sk, __u32 *cookie);
int sock_diag_put_meminfo(struct sock *sk, struct sk_buff *skb, int attr);
-extern struct sock *sock_diag_nlsk;
#endif /* KERNEL */
#endif
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index ac9195e..ae1cd6c 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -101,6 +101,7 @@ struct net {
struct netns_xfrm xfrm;
#endif
struct netns_ipvs *ipvs;
+ struct sock *diag_nlsk;
};
diff --git a/net/core/sock_diag.c b/net/core/sock_diag.c
index 07a29eb..d060251 100644
--- a/net/core/sock_diag.c
+++ b/net/core/sock_diag.c
@@ -166,23 +166,39 @@ static void sock_diag_rcv(struct sk_buff *skb)
mutex_unlock(&sock_diag_mutex);
}
-struct sock *sock_diag_nlsk;
-EXPORT_SYMBOL_GPL(sock_diag_nlsk);
+struct sock *diag_nlsk;
+EXPORT_SYMBOL_GPL(diag_nlsk);
-static int __init sock_diag_init(void)
+static int __net_init diag_net_init(struct net *net)
{
struct netlink_kernel_cfg cfg = {
.input = sock_diag_rcv,
};
- sock_diag_nlsk = netlink_kernel_create(&init_net, NETLINK_SOCK_DIAG,
+ net->diag_nlsk = netlink_kernel_create(net, NETLINK_SOCK_DIAG,
THIS_MODULE, &cfg);
- return sock_diag_nlsk == NULL ? -ENOMEM : 0;
+ return net->diag_nlsk == NULL ? -ENOMEM : 0;
+}
+
+static void __net_exit diag_net_exit(struct net *net)
+{
+ netlink_kernel_release(net->diag_nlsk);
+ net->diag_nlsk = NULL;
+}
+
+static struct pernet_operations diag_net_ops = {
+ .init = diag_net_init,
+ .exit = diag_net_exit,
+};
+
+static int __init sock_diag_init(void)
+{
+ return register_pernet_subsys(&diag_net_ops);
}
static void __exit sock_diag_exit(void)
{
- netlink_kernel_release(sock_diag_nlsk);
+ unregister_pernet_subsys(&diag_net_ops);
}
module_init(sock_diag_init);
diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c
index 38064a2..4703c58 100644
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c
@@ -272,6 +272,7 @@ int inet_diag_dump_one_icsk(struct inet_hashinfo *hashinfo, struct sk_buff *in_s
int err;
struct sock *sk;
struct sk_buff *rep;
+ struct net *net = sock_net(in_skb->sk);
err = -EINVAL;
if (req->sdiag_family == AF_INET) {
@@ -317,7 +318,7 @@ int inet_diag_dump_one_icsk(struct inet_hashinfo *hashinfo, struct sk_buff *in_s
nlmsg_free(rep);
goto out;
}
- err = netlink_unicast(sock_diag_nlsk, rep, NETLINK_CB(in_skb).pid,
+ err = netlink_unicast(net->diag_nlsk, rep, NETLINK_CB(in_skb).pid,
MSG_DONTWAIT);
if (err > 0)
err = 0;
@@ -724,6 +725,7 @@ void inet_diag_dump_icsk(struct inet_hashinfo *hashinfo, struct sk_buff *skb,
{
int i, num;
int s_i, s_num;
+ struct net *net = sock_net(skb->sk);
s_i = cb->args[1];
s_num = num = cb->args[2];
@@ -743,6 +745,9 @@ void inet_diag_dump_icsk(struct inet_hashinfo *hashinfo, struct sk_buff *skb,
sk_nulls_for_each(sk, node, &ilb->head) {
struct inet_sock *inet = inet_sk(sk);
+ if (!net_eq(sock_net(sk), net))
+ continue;
+
if (num < s_num) {
num++;
continue;
@@ -943,6 +948,7 @@ static int inet_diag_get_exact_compat(struct sk_buff *in_skb,
static int inet_diag_rcv_msg_compat(struct sk_buff *skb, struct nlmsghdr *nlh)
{
int hdrlen = sizeof(struct inet_diag_req);
+ struct net *net = sock_net(skb->sk);
if (nlh->nlmsg_type >= INET_DIAG_GETSOCK_MAX ||
nlmsg_len(nlh) < hdrlen)
@@ -963,7 +969,7 @@ static int inet_diag_rcv_msg_compat(struct sk_buff *skb, struct nlmsghdr *nlh)
struct netlink_dump_control c = {
.dump = inet_diag_dump_compat,
};
- return netlink_dump_start(sock_diag_nlsk, skb, nlh, &c);
+ return netlink_dump_start(net->diag_nlsk, skb, nlh, &c);
}
}
@@ -973,6 +979,7 @@ static int inet_diag_rcv_msg_compat(struct sk_buff *skb, struct nlmsghdr *nlh)
static int inet_diag_handler_dump(struct sk_buff *skb, struct nlmsghdr *h)
{
int hdrlen = sizeof(struct inet_diag_req_v2);
+ struct net *net = sock_net(skb->sk);
if (nlmsg_len(h) < hdrlen)
return -EINVAL;
@@ -991,7 +998,7 @@ static int inet_diag_handler_dump(struct sk_buff *skb, struct nlmsghdr *h)
struct netlink_dump_control c = {
.dump = inet_diag_dump,
};
- return netlink_dump_start(sock_diag_nlsk, skb, h, &c);
+ return netlink_dump_start(net->diag_nlsk, skb, h, &c);
}
}
diff --git a/net/ipv4/udp_diag.c b/net/ipv4/udp_diag.c
index a7f86a3..52f42f9 100644
--- a/net/ipv4/udp_diag.c
+++ b/net/ipv4/udp_diag.c
@@ -34,6 +34,7 @@ static int udp_dump_one(struct udp_table *tbl, struct sk_buff *in_skb,
int err = -EINVAL;
struct sock *sk;
struct sk_buff *rep;
+ struct net *net = sock_net(in_skb->sk);
if (req->sdiag_family == AF_INET)
sk = __udp4_lib_lookup(&init_net,
@@ -75,7 +76,7 @@ static int udp_dump_one(struct udp_table *tbl, struct sk_buff *in_skb,
kfree_skb(rep);
goto out;
}
- err = netlink_unicast(sock_diag_nlsk, rep, NETLINK_CB(in_skb).pid,
+ err = netlink_unicast(net->diag_nlsk, rep, NETLINK_CB(in_skb).pid,
MSG_DONTWAIT);
if (err > 0)
err = 0;
diff --git a/net/unix/diag.c b/net/unix/diag.c
index a74864e..750b134 100644
--- a/net/unix/diag.c
+++ b/net/unix/diag.c
@@ -177,6 +177,7 @@ static int unix_diag_dump(struct sk_buff *skb, struct netlink_callback *cb)
{
struct unix_diag_req *req;
int num, s_num, slot, s_slot;
+ struct net *net = sock_net(skb->sk);
req = nlmsg_data(cb->nlh);
@@ -192,6 +193,8 @@ static int unix_diag_dump(struct sk_buff *skb, struct netlink_callback *cb)
num = 0;
sk_for_each(sk, node, &unix_socket_table[slot]) {
+ if (!net_eq(sock_net(sk), net))
+ continue;
if (num < s_num)
goto next;
if (!(req->udiag_states & (1 << sk->sk_state)))
@@ -243,6 +246,7 @@ static int unix_diag_get_exact(struct sk_buff *in_skb,
struct sock *sk;
struct sk_buff *rep;
unsigned int extra_len;
+ struct net *net = sock_net(in_skb->sk);
if (req->udiag_ino == 0)
goto out_nosk;
@@ -273,7 +277,7 @@ again:
goto again;
}
- err = netlink_unicast(sock_diag_nlsk, rep, NETLINK_CB(in_skb).pid,
+ err = netlink_unicast(net->diag_nlsk, rep, NETLINK_CB(in_skb).pid,
MSG_DONTWAIT);
if (err > 0)
err = 0;
@@ -287,6 +291,7 @@ out_nosk:
static int unix_diag_handler_dump(struct sk_buff *skb, struct nlmsghdr *h)
{
int hdrlen = sizeof(struct unix_diag_req);
+ struct net *net = sock_net(skb->sk);
if (nlmsg_len(h) < hdrlen)
return -EINVAL;
@@ -295,7 +300,7 @@ static int unix_diag_handler_dump(struct sk_buff *skb, struct nlmsghdr *h)
struct netlink_dump_control c = {
.dump = unix_diag_dump,
};
- return netlink_dump_start(sock_diag_nlsk, skb, h, &c);
+ return netlink_dump_start(net->diag_nlsk, skb, h, &c);
} else
return unix_diag_get_exact(skb, h, nlmsg_data(h));
}
--
1.7.1
^ permalink raw reply related
* 2012春季111届广交会买家，群发软件，B2B询盘买家、thomasnet 采购商,海关数据,展会买家 仅300元!
From: 有效果再付款 @ 2012-07-16 12:18 UTC (permalink / raw)
To: neuro, ncarroll, neuwudan, nevanez, neveroverthehill, netdev,
netdeck, netzhj, netzu, neucaijuan
2012春季111届广交会买家，海关数据提单piers版，2008-2012年9届广交会数据。
一共10个包(数据是全行业的，可以按照关键词提取出来的)：
1，2012春季111届广交会买家现场询盘数据库新鲜出炉，超级新鲜买家，新鲜数据，容易成单！
2，购买后可以免费更新2012秋季广交会买家数据。太超值了。
3，2012最新全球展会现场买家库(与贸发同步),共46万条数据。 (按照行业分类)
4，2011,2010年,2009年,2008年 春季+秋季广交会买家名录，103 104 105 106 107 108,109,110 共六届 共120.6万数据。
5，48.68万条最新买家询盘，都带有Email，最有价值的询盘。
6，2011最新 B2B 英文国际站60万带联络方式询盘 最有价值询盘之一.
7，2010海关提单piers版1000万数据.
8，2011年到香港采购的国外客人名录(香港贸发局提供)，超级重要的买家。
9，2011年新增加的-美国B2B thomasnet 采购商名单。
10，群发软件安装与部署服务。
这些全有，共1280万 数据。
要的抓紧联系QQ: 460122641 或者立即回复邮箱: 460122641@qq.com
要的抓紧联系QQ: 460122641 或者立即回复邮箱: 460122641@qq.com
要的抓紧联系QQ: 460122641 或者立即回复邮箱: 460122641@qq.com
诚信为本，如果不信任本人,可以走淘宝交易,收到数据验证3天后再付款,这是对您最好的保障了。
小技巧：
把500万买家群发以一遍，均会有数千个回复的，这些就是非常高质量的买家。
使用我们送的群发软件，1-2周就可完全发完。
广交会买家按产品类别分类，分为以下几类：
1 办公设备
2 编织及藤铁工艺品
3 玻璃
4 餐厨用具
5 车辆
6 大型机械及设备
7 电子电气
8 电子消费品
9 纺织
10 服装
11 个人护理
12 工程机械
13 工具
14 化工
15 计算机及通讯
16 家居用品
17 家居装饰
18 家具
19 家用电器
20 建筑及装饰材料
21 节日用品
22 礼品及赠品
23 摩托车
24 汽车配件
25 食品
26 陶瓷
27 铁石
28 玩具
29 卫浴
30 五金
31 小型机械
32 鞋
33 休闲用品
34 医疗
35 浴室产品
36 园林
37 照明产品
38 钟表眼镜
39 自行车
40 包
新鲜数据-成单率极高
新鲜数据-成单率极高
新鲜数据-成单率极高
新鲜数据-成单率极高
新鲜数据-成单率极高
^ permalink raw reply
* Re: [PATCH] natsemi: make cable length magic configurable
From: Jean Delvare @ 2012-07-16 12:26 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, Tim Hockin, Olaf Kirch
In-Reply-To: <1322162739.2784.26.camel@bwh-desktop>
Hi Ben,
Thanks for you fast reply and sorry for my very slow one.
Le jeudi 24 novembre 2011 à 19:25 +0000, Ben Hutchings a écrit :
> On Thu, 2011-11-24 at 14:43 +0100, Jean Delvare wrote:
> > From: Olaf Kirch <okir@suse.de>
> >
> > We had a customer report concerning problems with a Natsemi DP83815-D
> > and long cables. With 100m cables, the network would be essentially dead,
> > not a single packet would get through either way. We had to apply the
> > patch below to make it work.
> >
> > The patch adds a module parameter named "no_cable_magic" that does
> > two things:
> >
> > - Unconditionally set the DSPCFG register to the
> > fixed value. Without this change, the chip apparently
> > never completes autonegotiation in the tested configuration.
> >
> > This has been an unconditional assignment for a long time,
> > until this was changed in 2.6.11 (there's an interesting
> > explanation in the ChangeLog, subject is
> > "[PATCH] natsemi long cable fix", bk commit is
> > 5871b81bf2b5cf188deab0d414dce104fcb69ca6, git commit in
> > tglx/history tree is c0d51c67f9c398279a95c5a7df387f2d9a586c98.
> >
> > - Skip the bit banging in {,un}do_cable_magic. It seems that
> > if we write the DSPCFG register as above, a rev D chip will report
> > all cables as "short cables", which do_cable_magic detects, and
> > trying to be helpful it will "fix" the attenuation coefficient.
> >
> > I admit the use of a module parameter is ugly, but I didn't find a sane
> > way to fix this - especially since the magic registers we're changing
> > are undocumented.
> [...]
>
> This could be implemented as an ethtool 'private flag'. However, the
> ethtool utility currently does not provide an interface to them.
> Perhaps you could implement both the private flag and the module
> parameter for now, and then drop the module parameter some time after
> the utility has been updated.
I see that you updated the ethtool utility meanwhile, thanks for doing
that.
> You would need to:
> 1. Number the flags starting from 0. Well, that was easy.
> 2. Implement {get,set}_priv_flags() operations to access all flags as
> a bitmask.
> 3. Expose the flag names as string set ETH_SS_PRIV_FLAGS accessed by
> get_sset_count() and get_strings() operations.
I was looking for an example, but there doesn't seem to be any driver
implementing private flags at the moment?
I am also unsure if a private flag is a suitable solution to the problem
at hand. I am a little worried about the timing, as the non-default
value can't be set before the network device is available, I'm afraid
the network initialization scripts may kick in before one has a chance
to set the flag with ethtool. I suppose this could be problematic, but
then again I don't know much about network device drivers, I don't even
know for sure when method .ndo_open is called...
Furthermore I don't quite get why we can't just go with the module
parameter. As I understand it, this is a crappy driver for crappy, rare
hardware. The driver already has a module parameter to work around a
hardware bug (dspcfg_workaround), I don't quite see why adding a second
one would be a problem. At least it is consistent.
Thanks,
--
Jean Delvare
Suse L3
^ permalink raw reply
* [RESEND] lpc_eth: remove duplicated include
From: Duan Jiong @ 2012-07-16 12:29 UTC (permalink / raw)
To: davem; +Cc: netdev
Remove duplicated #include <linux/delay.h> in
drivers/net/ethernet/nxp/lpc_eth.c
Signed-off-by: Duan Jiong<djduanjiong@gmail.com>
---
drivers/net/ethernet/nxp/lpc_eth.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
index 083d671..a1fe179 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -44,7 +44,6 @@
#include <linux/of_net.h>
#include <linux/types.h>
-#include <linux/delay.h>
#include <linux/io.h>
#include <mach/board.h>
#include <mach/platform.h>
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] net-next: make sock diag per-namespace
From: Eric Dumazet @ 2012-07-16 12:32 UTC (permalink / raw)
To: Andrew Vagin
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Pavel Emelyanov, linux-kernel,
netdev
In-Reply-To: <1342440849-1757320-1-git-send-email-avagin@openvz.org>
On Mon, 2012-07-16 at 16:14 +0400, Andrew Vagin wrote:
> Before this patch sock_diag works for init_net only and dumps
> information about sockets from all namespaces.
...
> diff --git a/net/ipv4/udp_diag.c b/net/ipv4/udp_diag.c
> index a7f86a3..52f42f9 100644
> --- a/net/ipv4/udp_diag.c
> +++ b/net/ipv4/udp_diag.c
> @@ -34,6 +34,7 @@ static int udp_dump_one(struct udp_table *tbl, struct sk_buff *in_skb,
> int err = -EINVAL;
> struct sock *sk;
> struct sk_buff *rep;
> + struct net *net = sock_net(in_skb->sk);
>
> if (req->sdiag_family == AF_INET)
> sk = __udp4_lib_lookup(&init_net,
It seems you didnt fix udp_dump_one() correctly, since it
still mentions &init_net
> @@ -75,7 +76,7 @@ static int udp_dump_one(struct udp_table *tbl, struct sk_buff *in_skb,
> kfree_skb(rep);
> goto out;
> }
> - err = netlink_unicast(sock_diag_nlsk, rep, NETLINK_CB(in_skb).pid,
> + err = netlink_unicast(net->diag_nlsk, rep, NETLINK_CB(in_skb).pid,
> MSG_DONTWAIT);
> if (err > 0)
> err = 0;
udp_dump() also needs some care ?
^ permalink raw reply
* Re: [PATCH] net-next: make sock diag per-namespace
From: Andrew Vagin @ 2012-07-16 12:38 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andrew Vagin, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Pavel Emelianov,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <1342441945.23494.23.camel@edumazet-glaptop>
On Mon, Jul 16, 2012 at 04:32:25PM +0400, Eric Dumazet wrote:
> On Mon, 2012-07-16 at 16:14 +0400, Andrew Vagin wrote:
> > Before this patch sock_diag works for init_net only and dumps
> > information about sockets from all namespaces.
>
> ...
>
> > diff --git a/net/ipv4/udp_diag.c b/net/ipv4/udp_diag.c
> > index a7f86a3..52f42f9 100644
> > --- a/net/ipv4/udp_diag.c
> > +++ b/net/ipv4/udp_diag.c
> > @@ -34,6 +34,7 @@ static int udp_dump_one(struct udp_table *tbl, struct sk_buff *in_skb,
> > int err = -EINVAL;
> > struct sock *sk;
> > struct sk_buff *rep;
> > + struct net *net = sock_net(in_skb->sk);
> >
> > if (req->sdiag_family == AF_INET)
> > sk = __udp4_lib_lookup(&init_net,
>
> It seems you didnt fix udp_dump_one() correctly, since it
> still mentions &init_net
You are right. Sorry for this stupid fault. I will send a new patch.
>
> > @@ -75,7 +76,7 @@ static int udp_dump_one(struct udp_table *tbl, struct sk_buff *in_skb,
> > kfree_skb(rep);
> > goto out;
> > }
> > - err = netlink_unicast(sock_diag_nlsk, rep, NETLINK_CB(in_skb).pid,
> > + err = netlink_unicast(net->diag_nlsk, rep, NETLINK_CB(in_skb).pid,
> > MSG_DONTWAIT);
> > if (err > 0)
> > err = 0;
>
> udp_dump() also needs some care ?
>
>
Yes
^ permalink raw reply
* Re: resurrecting tcphealth
From: Piotr Sawuk @ 2012-07-16 13:03 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <1342439185.23494.19.camel@edumazet-glaptop>
On Mo, 16.07.2012, 13:46, Eric Dumazet wrote:
> On Mon, 2012-07-16 at 13:33 +0200, Piotr Sawuk wrote:
>> On Sa, 14.07.2012, 01:55, Stephen Hemminger wrote:
>> > I am not sure if the is really necessary since the most
>> > of the stats are available elsewhere.
>>
>> if by "most" you mean address and port then you're right.
>> but even the rtt reported by "ss -i" seems to differ from tcphealth.
>
> Thats because tcphealth is wrong, it assumes HZ=1000 ?
>
> tp->srtt unit is jiffies, not ms.
thanks. any conversion-functions in the kernel for that?
>
> tcphealth is a gross hack.
what would you do if you tried making it less gross?
I've not found any similar functionality, in the kernel.
I want to know an estimate for the percentage of data lost in tcp.
and I want to know that without actually sending much packets.
afterall I'm on the receiving end most of the time.
percentage of duplicate packets received is nice too.
you have any suggestions?
^ permalink raw reply
* Re: [PATCH] natsemi: make cable length magic configurable
From: Ben Hutchings @ 2012-07-16 13:08 UTC (permalink / raw)
To: Jean Delvare; +Cc: netdev, Tim Hockin, Olaf Kirch
In-Reply-To: <1342441581.4165.235.camel@amber.site>
On Mon, 2012-07-16 at 14:26 +0200, Jean Delvare wrote:
[...]
> > You would need to:
> > 1. Number the flags starting from 0. Well, that was easy.
> > 2. Implement {get,set}_priv_flags() operations to access all flags as
> > a bitmask.
> > 3. Expose the flag names as string set ETH_SS_PRIV_FLAGS accessed by
> > get_sset_count() and get_strings() operations.
>
> I was looking for an example, but there doesn't seem to be any driver
> implementing private flags at the moment?
No.
> I am also unsure if a private flag is a suitable solution to the problem
> at hand. I am a little worried about the timing, as the non-default
> value can't be set before the network device is available, I'm afraid
> the network initialization scripts may kick in before one has a chance
> to set the flag with ethtool. I suppose this could be problematic, but
> then again I don't know much about network device drivers, I don't even
> know for sure when method .ndo_open is called...
It's called when the interface is brought up (ifconfig up, ip link set
up, start NetworkManager...). Some distributions provide a
configuration option(s) to run ethtool while bringing an interface up.
> Furthermore I don't quite get why we can't just go with the module
> parameter. As I understand it, this is a crappy driver for crappy, rare
> hardware. The driver already has a module parameter to work around a
> hardware bug (dspcfg_workaround), I don't quite see why adding a second
> one would be a problem. At least it is consistent.
David can be quite insistent about finding an alternative to module
parameters.
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: resurrecting tcphealth
From: Ben Hutchings @ 2012-07-16 13:32 UTC (permalink / raw)
To: Piotr Sawuk; +Cc: netdev, linux-kernel
In-Reply-To: <cc6495b92f1df180c1ad43057ceb0b98.squirrel@webmail.univie.ac.at>
On Sat, 2012-07-14 at 09:56 +0200, Piotr Sawuk wrote:
> On Sa, 14.07.2012, 03:31, valdis.kletnieks@vt.edu wrote:
> > On Fri, 13 Jul 2012 16:55:44 -0700, Stephen Hemminger said:
> >
> >> >+ /* Course retransmit inefficiency- this packet has been received
> >> twice. */
> >> >+ tp->dup_pkts_recv++;
> >> I don't understand that comment, could you use a better sentence please?
> >
> > I think what was intended was:
> >
> > /* Curse you, retransmit inefficiency! This packet has been received at
> least twice */
> >
>
> LOL, no. I think "course retransmit" is short for "course-grained timeout
> caused retransmit" but I can't be sure since I'm not the author of these
> lines. I'll replace that comment with the non-shorthand version though.
> however, I think the real comment here should be:
[...]
The word you are looking for is 'coarse' not 'course' (they are
generally pronounced the same, to confuse you).
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: 3.4.2 net/ipv6/mip6.c destopt regression
From: András Takács @ 2012-07-16 13:40 UTC (permalink / raw)
To: netdev
In-Reply-To: <A81B4C3A-8B30-4860-BFE1-AE91F7F0DD6E@wakoond.hu>
Dear All,
I have serious problems with HAO dest opt XFRM processing. In the past few days I have tried to find the problem, and I figured out the following:
1. case: No XFRM rules
It works fine (as it was described in my previous e-mail)
2. case: HAO RO XFRM processing
I have created the following rules manually:
sudo ip -6 xfrm policy add src 2001:470:7210:10::11 dst 2001:470:7210:10::1000 proto 135 type 5 dir out priority 2 ptype sub tmpl src 2001:470:7210:10::11 dst 2001:470:7210:10::1000 proto hao reqid 0 mode ro
sudo ip -6 xfrm state add src 2001:470:7210:10::11 dst 2001:470:7210:10::1000 proto hao reqid 0 mode ro replay-window 0 coa 2001:470:7210:11:20c:29ff:fe46:a0e3 sel src 2001:470:7210:10::11 dst 2001:470:7210:10::1000
The message format is corrupted, because during the xfrm processing, the beginning of the MH part will be overwritten by the DST OPT header.
3. case: ESP TUNNEL XFRM
I have created ESP TUNNEL XFRM rules manually, and it was worked fine.
So the problem has to be somewhere in the net/ipv6/mip6.c or net/ipv6/xfrm_mode_ro.c files.
-------------
I added a lot of debug printk statements to the source, and I have figured out the following:
When the kernel creates the skb from the iovec, it seems to be ok (in ip6_append_data):
skb->data to skb->tail:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 57 39 B1 FB 87 39 B1 FB 64 92 FF FF 18 00 00 00 00 00 00 00 00 00 00 00 3B 03 05 00 00 00 00 01 00 00 00 02 01 00 03 10 20 01 04 70 72 10 00 11 02 0C 29 FF FE 46 A0 E3
Unfortunately at the beginning of the xfrm6_ro_output function, it seems to be corrupt:
60 00 00 00 00 08 87 40 20 01 04 70 72 10 00 10 00 00 00 00 00 00 00 11 20 01 04 70 72 10 00 10 00 00 00 00 00 00 10 00 02 0C 29 FF FE 46 A0 E3
Here missing the first 24 bytes of the MH part. It is quite suspicious, because the size of the DST OPT header (with the necessary padding) is exactly same long.
After this point xfrm6_ro_output and mip6_destopt_output works fine, and insert the DST OPT header to this truncated skb.
Could you please help me to find the connection ("call - graph" ?) between ip6_append_data and xfrm6_ro_output? I can't find the point where it fails. In ip6_append_data, the beginning of the skb is reserved for the IPv6 header, but where will be this part filled with the right values?
Thank you very much for your help!
Regards,
András
On Jun 21, 2012, at 10:41 PM, Andras Takacs wrote:
> Dear All,
>
> I'm working with Mobile IPv6 systems, and I'm setting up a new MIP6 environment. I would like to use the latest stable kernel, so I'm using 3.4.2. Unfortunately I have some serious problems with destination option XFRM processing. I have done the following tests to find the issue:
>
> First case: No XFRM policies and states.
> Sending MH messages without destopt header.
> In this case the message format is OK, I have tested it with tcpdump and wireshark.
>
> 21:33:58.817130 IP6 2001:470:7210:10::11 > 2001:470:7210:10::1000: mobility: BU seq#=1 lifetime=8
> 0x0000: 6000 0000 0020 8740 2001 0470 7210 0010 `......@...pr...
> 0x0010: 0000 0000 0000 0011 2001 0470 7210 0010 ...........pr...
> 0x0020: 0000 0000 0000 1000 3b03 0500 1c46 0001 ........;....F..
> 0x0030: 0000 0002 0100 0310 2001 0470 7210 0011 ...........pr...
> 0x0040: 020c 29ff fe46 a0e3 ..)..F..
>
> Second case: Adding destopt XFRM policy and state:
>
> ip -6 xfrm policy add src 2001:470:7210:10::11 dst 2001:470:7210:10::1000 proto 135 type 5 dir out priority 2 ptype sub tmpl src 2001:470:7210:10::11 dst 2001:470:7210:10::1000 proto hao reqid 0 mode ro level use
> ip -6 xfrm state add src 2001:470:7210:10::11 dst 2001:470:7210:10::1000 proto hao reqid 0 mode ro replay-window 0 coa 2001:470:7210:11:20c:29ff:fe46:a0e3 sel src 2001:470:7210:10::11 dst 2001:470:7210:10::1000
>
> In this case, the message format is corrupted:
>
> 21:30:42.350315 IP6 2001:470:7210:11:20c:29ff:fe46:a0e3 > 2001:470:7210:10::1000: DSTOPT mobility: type-#41 len=12
> 0x0000: 6000 0000 0020 3c40 2001 0470 7210 0011 `.....<@...pr...
> 0x0010: 020c 29ff fe46 a0e3 2001 0470 7210 0010 ..)..F.....pr...
> 0x0020: 0000 0000 0000 1000 8702 0102 0000 c910 ................
> 0x0030: 2001 0470 7210 0010 0000 0000 0000 0011 ...pr...........
> 0x0040: 020c 29ff fe46 a0e3
>
> As you can see, the IPv6 header is OK. Next, the destination option header is OK. Finally, the following part of the packet isn't OK. If you compare the two dump carefully, you will see, that the last 8 bytes are identical. The mip6_destopt_output function adds the destination option header correctly, but overwrites the existing MH header, and doesn't shift it after the destopt header.
>
> I'm not familiar with the XFRM framework enough to fix the problem. :(
> Maybe, could anyone help to me to fix this issue?
>
> The last environment, which worked fine was built on 2.6.35 version. The problem happened between 2.6.35 and 3.4.2. Sorry, I know, it is a quite big interval. :(
>
> Thanks!
>
>
> Best regards,
> András Takács
^ permalink raw reply
* where timer expiry check is happening before sending ICMP_REPLY in ipv6
From: BALAKUMARAN KANNAN @ 2012-07-16 13:41 UTC (permalink / raw)
To: netdev@vger.kernel.org
In-Reply-To: <4A71D24947E78D43BC584A7CD4391A41017DBB86@SIXPRD0410MB359.apcprd04.prod.outlook.com>
Dear all,
In kernel-3.0.26 code net/ipv6/icmp.c, while sending ICMP reply where it checks for the timer expiry. It should check the value given by a router advertisement. I think the expiry value is stored in
rt->rt6_expires in ndisc.c (line no: 1284). Then while sending an ICMP reply, it should check with the expiry timer right? Where that check is happening? Please somebody explain me.
Thank you.
--Regards,
K.Balakumaran
^ permalink raw reply
* timer expiry check at icmp.c in ipv6
From: BALAKUMARAN KANNAN @ 2012-07-16 13:44 UTC (permalink / raw)
To: netdev@vger.kernel.org
Dear all,
In kernel-3.0.26 code net/ipv6/icmp.c, while sending ICMP reply where it checks for the timer expiry. It should check the value given by a router advertisement. I think the expiry value is stored in rt->rt6_expires in ndisc.c (line no: 1284). Then while sending an ICMP reply, it should check with the expiry timer right? Where that check is happening? Please somebody explain me.
Thank you.
--Regards,
K.Balakumaran
^ 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