* [PATCH] net: mvneta: fix Tx interrupt delay
From: Willy Tarreau @ 2014-12-02 7:13 UTC (permalink / raw)
To: netdev; +Cc: Maggie Mae Roxas, Thomas Petazzoni, Gregory CLEMENT,
Ezequiel Garcia
The mvneta driver sets the amount of Tx coalesce packets to 16 by
default. Normally that does not cause any trouble since the driver
uses a much larger Tx ring size (532 packets). But some sockets
might run with very small buffers, much smaller than the equivalent
of 16 packets. This is what ping is doing for example, by setting
SNDBUF to 324 bytes rounded up to 2kB by the kernel.
The problem is that there is no documented method to force a specific
packet to emit an interrupt (eg: the last of the ring) nor is it
possible to make the NIC emit an interrupt after a given delay.
In this case, it causes trouble, because when ping sends packets over
its raw socket, the few first packets leave the system, and the first
15 packets will be emitted without an IRQ being generated, so without
the skbs being freed. And since the socket's buffer is small, there's
no way to reach that amount of packets, and the ping ends up with
"send: no buffer available" after sending 6 packets. Running with 3
instances of ping in parallel is enough to hide the problem, because
with 6 packets per instance, that's 18 packets total, which is enough
to grant a Tx interrupt before all are sent.
The original driver in the LSP kernel worked around this design flaw
by using a software timer to clean up the Tx descriptors. This timer
was slow and caused terrible network performance on some Tx-bound
workloads (such as routing) but was enough to make tools like ping
work correctly.
Instead here, we simply set the packet counts before interrupt to 1.
This ensures that each packet sent will produce an interrupt. NAPI
takes care of coalescing interrupts since the interrupt is disabled
once generated.
No measurable performance impact nor CPU usage were observed on small
nor large packets, including when saturating the link on Tx, and this
fixes tools like ping which rely on too small a send buffer. If one
wants to increase this value for certain workloads where it is safe
to do so, "ethtool -C $dev tx-frames" will override this default
setting.
This fix needs to be applied to stable kernels starting with 3.10.
Tested-By: Maggie Mae Roxas <maggie.mae.roxas@gmail.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
drivers/net/ethernet/marvell/mvneta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 4762994..35bfba7 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -214,7 +214,7 @@
/* Various constants */
/* Coalescing */
-#define MVNETA_TXDONE_COAL_PKTS 16
+#define MVNETA_TXDONE_COAL_PKTS 1
#define MVNETA_RX_COAL_PKTS 32
#define MVNETA_RX_COAL_USEC 100
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related
* Re: [RFC PATCH] netfilter: conntrack: cache route for forwarded connections
From: Julian Anastasov @ 2014-12-02 7:15 UTC (permalink / raw)
To: Florian Westphal; +Cc: netfilter-devel, brouer, netdev
In-Reply-To: <1417480114-3002-1-git-send-email-fw@strlen.de>
Hello,
On Tue, 2 Dec 2014, Florian Westphal wrote:
> ... to avoid per-packet FIB lookup if possible.
>
> The cached dst is re-used provided the input interface
> is the same as that of the previous packet in the same direction.
>
> If not, the cached dst is invalidated.
>
> This should speed up forwarding when conntrack is already in use
> anyway, especially when using reverse path filtering -- active RPF
> enforces two FIB lookups for each packet.
>
> Before the routing cache removal this didn't matter since RPF
> was performed only when route cache didn't yield a result; but without
> route cache it comes at high price.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> ---
> Sending as RFC since I haven't tested this yet (aside from
> single-forwarded-flow), so no performance data either.
>
> - doesn't work when iif changes (it invalidates cached dst), don't
> think its a problem
The idea is good. But code that caches dsts should
also handle at least NETDEV_UNREGISTER (NETDEV_DOWN being
another option) to release dsts. Holding dsts for frozen
conns in EST state for long time is a problem. IIRC, such dsts
are not under dst_dev_event() control. nf_nat_masquerade_ipv4.c
has something like this but for masq_index.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH v3 net-next] net: bcmgenet: enable driver to work without a device tree
From: Florian Fainelli @ 2014-12-02 7:24 UTC (permalink / raw)
To: Petri Gynther; +Cc: netdev, David Miller
In-Reply-To: <20141202001808.9B0E6220728@puck.mtv.corp.google.com>
2014-12-01 16:18 GMT-08:00 Petri Gynther <pgynther@google.com>:
> Modify bcmgenet driver so that it can be used on Broadcom 7xxx
> MIPS-based STB platforms without a device tree.
Have not seen any regressions with DT-only platforms, thanks!
>
> Signed-off-by: Petri Gynther <pgynther@google.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Kevin Zhu @ 2014-12-02 7:44 UTC (permalink / raw)
To: Enrico Mioso
Cc: Eli Britstein, Bjørn Mork, Alex Strizhevsky,
Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <alpine.LNX.2.03.1412020747360.1921-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 6732 bytes --]
Hi all,
Here's the registry from windows 7. Attached. One parameter that might
be interesting is MaxNumOfDatagramInNTB, which is 64. I wonder if it has
something to do with MaxDatagramSize. Can someone also check the
registry, in case I missed something?
Regards,
Kevin
On 12/02/2014 02:49 PM, Enrico Mioso wrote:
> Can you try to look at Windows registry keys based on the INF file as suggested
> or would this be a problem for you?
> And... if you have any Huawei manutal talking about it: even device's
> ^DSFLOWRPT
> might be useful to some extent, but ... this is only just a note in case we
> don't find anything else.
> Regards ... and good day to all of you,
> Enrico
>
>
> On Tue, 2 Dec 2014, Kevin Zhu wrote:
>
> ==Date: Tue, 2 Dec 2014 07:43:24
> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
> ==To: Enrico Mioso <mrkiko.rs@gmail.com>
> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, Bjørn Mork <bjorn@mork.no>,
> == Alex Strizhevsky <alexxst@gmail.com>,
> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
> == "youtux@gmail.com" <youtux@gmail.com>,
> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
> ==Subject: Re: Is this 32-bit NCM?
> ==
> ==I also tried to define CDC_NCM_DPT_DATAGRAMS_MAX as 1 to eliminate the
> ==paddings, but it did not work either, not even DHCP.
> ==
> ==Regards,
> ==Kevin
> ==
> ==On 12/02/2014 02:32 PM, Enrico Mioso wrote:
> ==> Hi again Eli,
> ==> Hi Kevin,
> ==> Hi everyone...
> ==>
> ==> As I understand it anyway - the distinction here tends not to be between
> ==> different types of packets.
> ==> It tends to be between received and sent packet.
> ==> We are not able to generate packets that the device retains valid.
> ==> If you manually configure the IP the device would have assigned you via DHCP,
> ==> your system will start answering ARP request, saying that the host with IP
> ==> aa.bb.cc.dd is at aa:bb:cc:dd:ee (using the MC address of the dongle).
> ==> However, the other host (gateway) will never know that. Indeed, it'll continue
> ==> asking who-is at aa.bb.cc.dd ?
> ==> At least, this is the situation I observed in the test system.
> ==>
> ==>
> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote:
> ==>
> ==> ==Date: Tue, 2 Dec 2014 04:53:53
> ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
> ==> ==To: Eli Britstein <Eli.Britstein@audiocodes.com>,
> ==> == Enrico Mioso <mrkiko.rs@gmail.com>
> ==> ==Cc: Bjørn Mork <bjorn@mork.no>, Alex Strizhevsky <alexxst@gmail.com>,
> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
> ==> == "youtux@gmail.com" <youtux@gmail.com>,
> ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
> ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
> ==> ==Subject: Re: Is this 32-bit NCM?
> ==> ==
> ==> ==Hi,
> ==> ==
> ==> ==The DHCP packets have the maximum size of dwNtbOutMaxSize=16384, while
> ==> ==the other packets are less than that. However, the DHCP queries are not
> ==> ==replied in time either, there's always some delay.
> ==> ==
> ==> ==By the way, though the device claims to support GET_MAX_DATAGRAM_SIZE,
> ==> ==but it returns error when the host sends this command to it. I disabled
> ==> ==this command in NCM driver and tried, but it's the same result.
> ==> ==
> ==> ==Regards,
> ==> ==Kevin
> ==> ==
> ==> ==On 12/02/2014 06:02 AM, Eli Britstein wrote:
> ==> ==> Hi Enrico and all,
> ==> ==>
> ==> ==> Maybe I missed something but what is the difference by the driver point of view between the dhcp discover and request (that are ok) to others (like arp, that is nok)?
> ==> ==> Maybe we can trace to compare them?
> ==> ==>
> ==> ==> Sent from my iPhone
> ==> ==>
> ==> ==>> On 1 בדצמ 2014, at 23:11, "Enrico Mioso" <mrkiko.rs@gmail.com> wrote:
> ==> ==>>
> ==> ==>> So ... I have two ideas left for now.
> ==> ==>> We know for sure the problem is in the way we TX frames, not the way we RX them
> ==> ==>> (the way we send, generate them, not the way we receive them).
> ==> ==>> Si I have two ideas, and I ask for help from the Linux-usb mailing list for
> ==> ==>> this first one.
> ==> ==>>
> ==> ==>> 1 - Does a wayexist to "replay" traffic crom a usb capture?
> ==> ==>> We might try to take the usb frames generated by Windows, and send them to the
> ==> ==>> device to see if there is any reaction. It should not be science fiction, I saw
> ==> ==>> them do that in the eciadsl old project.
> ==> ==>> 2 - The huawei ndis driver: does it work with these devices?
> ==> ==>> It should be a little bit out-dated now (at least in terms of dates, it might
> ==> ==>> work as well): the code is A LOT but, just in case, to see if there is any
> ==> ==>> chances it'll work. It remains to be seen in which kernels it can actually
> ==> ==>> compile again.
> ==> ==>>
> ==> ==>> If this works we might analyse what's happening and try to debug this out.
> ==> ==>> But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm.
> ==> ==>> Thank you.
> ==> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
> ==> ==
> ==> ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
> ==> ==
> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
> ==
> ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
> ==
This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: e3372.reg --]
[-- Type: text/x-ms-regedit; name="e3372.reg", Size: 10292 bytes --]
ÿþW\0i\0n\0d\0o\0w\0s\0 \0R\0e\0g\0i\0s\0t\0r\0y\0 \0E\0d\0i\0t\0o\0r\0 \0V\0e\0r\0s\0i\0o\0n\0 \05\0.\00\00\0\r\0
\0\r\0
\0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0]\0\r\0
\0"\0N\0e\0w\0D\0e\0v\0i\0c\0e\0I\0n\0s\0t\0a\0l\0l\0"\0=\0d\0w\0o\0r\0d\0:\00\00\00\00\00\00\00\01\0\r\0
\0"\0N\0e\0t\0C\0f\0g\0I\0n\0s\0t\0a\0n\0c\0e\0I\0d\0"\0=\0"\0{\02\04\04\04\03\00\0E\05\0-\0F\06\0B\01\0-\04\0E\09\0C\0-\09\00\01\01\0-\04\01\03\0B\07\0E\02\04\05\09\08\0C\0}\0"\0\r\0
\0"\0*\0I\0f\0T\0y\0p\0e\0"\0=\0d\0w\0o\0r\0d\0:\00\00\00\00\00\00\0f\03\0\r\0
\0"\0C\0h\0a\0r\0a\0c\0t\0e\0r\0i\0s\0t\0i\0c\0s\0"\0=\0d\0w\0o\0r\0d\0:\00\00\00\00\00\00\08\04\0\r\0
\0"\0*\0M\0e\0d\0i\0a\0T\0y\0p\0e\0"\0=\0d\0w\0o\0r\0d\0:\00\00\00\00\00\00\00\09\0\r\0
\0"\0*\0P\0h\0y\0s\0i\0c\0a\0l\0M\0e\0d\0i\0a\0T\0y\0p\0e\0"\0=\0d\0w\0o\0r\0d\0:\00\00\00\00\00\00\00\08\0\r\0
\0"\0N\0e\0t\0L\0u\0i\0d\0I\0n\0d\0e\0x\0"\0=\0d\0w\0o\0r\0d\0:\00\00\00\00\00\00\00\00\0\r\0
\0"\0D\0e\0v\0i\0c\0e\0I\0n\0s\0t\0a\0n\0c\0e\0I\0D\0"\0=\0"\0U\0S\0B\0\\0\\0V\0I\0D\0_\01\02\0D\01\0&\0S\0U\0B\0C\0L\0A\0S\0S\0_\00\03\0&\0P\0R\0O\0T\0_\01\06\0\\0\\07\0&\04\06\0B\06\05\0F\01\0&\00\0&\00\00\00\02\0"\0\r\0
\0"\0I\0n\0s\0t\0a\0l\0l\0T\0i\0m\0e\0S\0t\0a\0m\0p\0"\0=\0h\0e\0x\0:\0d\0e\0,\00\07\0,\00\0a\0,\00\00\0,\00\03\0,\00\00\0,\00\08\0,\00\00\0,\00\01\0,\00\00\0,\03\01\0,\00\00\0,\01\0d\0,\00\00\0,\0c\0f\0,\00\00\0\r\0
\0"\0B\0u\0s\0N\0u\0m\0b\0e\0r\0"\0=\0"\00\0"\0\r\0
\0"\0M\0P\0R\0a\0d\0i\0o\0S\0t\0a\0t\0e\0"\0=\0d\0w\0o\0r\0d\0:\00\00\00\00\00\00\00\01\0\r\0
\0"\0B\0u\0s\0T\0y\0p\0e\0"\0=\0"\01\05\0"\0\r\0
\0"\0C\0o\0m\0p\0o\0n\0e\0n\0t\0I\0d\0"\0=\0"\0u\0s\0b\0\\0\\0v\0i\0d\0_\01\02\0d\01\0&\0s\0u\0b\0c\0l\0a\0s\0s\0_\00\03\0&\0p\0r\0o\0t\0_\01\06\0"\0\r\0
\0"\0d\0i\0s\0a\0b\0l\0e\0_\0a\0c\0c\0u\0m\0u\0l\0a\0t\0i\0o\0n\0_\0u\0p\0d\0a\0t\0e\0"\0=\0"\00\0"\0\r\0
\0"\0F\0l\0o\0w\0C\0o\0n\0t\0r\0o\0l\0T\0i\0m\0e\0O\0u\0t\0"\0=\0"\02\08\00\00\0"\0\r\0
\0"\0F\0r\0a\0m\0e\0T\0y\0p\0e\0"\0=\0"\00\0"\0\r\0
\0"\0I\0s\0N\0t\0b\03\02\0"\0=\0"\01\0"\0\r\0
\0"\0M\0a\0x\0N\0u\0m\0O\0f\0D\0a\0t\0a\0g\0r\0a\0m\0s\0I\0n\0N\0T\0B\0"\0=\0"\06\04\0"\0\r\0
\0"\0N\0c\0m\0R\0e\0i\0n\0i\0t\0i\0a\0l\0i\0z\0e\0E\0n\0a\0b\0l\0e\0"\0=\0"\01\0"\0\r\0
\0"\0N\0T\0B\0I\0n\0p\0u\0t\0S\0i\0z\0e\0"\0=\0"\00\0"\0\r\0
\0"\0P\0a\0c\0k\0e\0t\0s\0A\0c\0c\0u\0m\0u\0l\0a\0t\0i\0o\0n\0T\0i\0m\0e\0o\0u\0t\0"\0=\0"\02\00\0"\0\r\0
\0"\0P\0r\0o\0m\0i\0s\0c\0u\0o\0u\0s\0"\0=\0"\00\0"\0\r\0
\0"\0W\0w\0a\0n\0M\0b\0i\0m\0E\0n\0a\0b\0l\0e\0"\0=\0"\00\0"\0\r\0
\0"\0I\0n\0f\0P\0a\0t\0h\0"\0=\0"\0o\0e\0m\05\04\0.\0i\0n\0f\0"\0\r\0
\0"\0I\0n\0f\0S\0e\0c\0t\0i\0o\0n\0"\0=\0"\0e\0w\0_\0w\0w\0a\0n\0e\0c\0m\0.\0n\0d\0i\0"\0\r\0
\0"\0P\0r\0o\0v\0i\0d\0e\0r\0N\0a\0m\0e\0"\0=\0"\0H\0U\0A\0W\0E\0I\0"\0\r\0
\0"\0D\0r\0i\0v\0e\0r\0D\0a\0t\0e\0D\0a\0t\0a\0"\0=\0h\0e\0x\0:\00\00\0,\00\00\0,\07\0f\0,\07\0a\0,\07\04\0,\05\07\0,\0c\0f\0,\00\01\0\r\0
\0"\0D\0r\0i\0v\0e\0r\0D\0a\0t\0e\0"\0=\0"\04\0-\01\04\0-\02\00\01\04\0"\0\r\0
\0"\0D\0r\0i\0v\0e\0r\0V\0e\0r\0s\0i\0o\0n\0"\0=\0"\01\0.\00\0.\01\03\0.\00\0"\0\r\0
\0"\0M\0a\0t\0c\0h\0i\0n\0g\0D\0e\0v\0i\0c\0e\0I\0d\0"\0=\0"\0u\0s\0b\0\\0\\0v\0i\0d\0_\01\02\0d\01\0&\0s\0u\0b\0c\0l\0a\0s\0s\0_\00\03\0&\0p\0r\0o\0t\0_\01\06\0"\0\r\0
\0"\0D\0r\0i\0v\0e\0r\0D\0e\0s\0c\0"\0=\0"\0H\0U\0A\0W\0E\0I\0 \0M\0o\0b\0i\0l\0e\0 \0C\0o\0n\0n\0e\0c\0t\0 \0-\0 \0N\0e\0t\0w\0o\0r\0k\0 \0C\0a\0r\0d\0"\0\r\0
\0"\0E\0n\0a\0b\0l\0e\0D\0h\0c\0p\0"\0=\0d\0w\0o\0r\0d\0:\00\00\00\00\00\00\00\00\0\r\0
\0"\0h\0w\0_\0n\0d\0i\0s\0_\0c\0o\0n\0t\0r\0o\0l\0_\0f\0i\0l\0e\0"\0=\0"\0\\0\\0D\0o\0s\0D\0e\0v\0i\0c\0e\0s\0\\0\\0H\0w\0U\0s\0b\0N\0d\0i\0s\00\0"\0\r\0
\0\r\0
\0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0L\0i\0n\0k\0a\0g\0e\0]\0\r\0
\0"\0R\0o\0o\0t\0D\0e\0v\0i\0c\0e\0"\0=\0h\0e\0x\0(\07\0)\0:\07\0b\0,\00\00\0,\03\02\0,\00\00\0,\03\04\0,\00\00\0,\03\04\0,\00\00\0,\03\04\0,\00\00\0,\03\03\0,\00\00\0,\03\00\0,\00\00\0,\04\05\0,\00\00\0,\03\05\0,\00\00\0,\02\0d\0,\0\\0\r\0
\0 \0 \00\00\0,\04\06\0,\00\00\0,\03\06\0,\00\00\0,\04\02\0,\00\00\0,\03\01\0,\00\00\0,\02\0d\0,\00\00\0,\03\04\0,\00\00\0,\04\05\0,\00\00\0,\03\09\0,\00\00\0,\04\03\0,\00\00\0,\02\0d\0,\00\00\0,\03\09\0,\00\00\0,\03\00\0,\00\00\0,\0\\0\r\0
\0 \0 \03\01\0,\00\00\0,\03\01\0,\00\00\0,\02\0d\0,\00\00\0,\03\04\0,\00\00\0,\03\01\0,\00\00\0,\03\03\0,\00\00\0,\04\02\0,\00\00\0,\03\07\0,\00\00\0,\04\05\0,\00\00\0,\03\02\0,\00\00\0,\03\04\0,\00\00\0,\03\05\0,\00\00\0,\03\09\0,\0\\0\r\0
\0 \0 \00\00\0,\03\08\0,\00\00\0,\04\03\0,\00\00\0,\07\0d\0,\00\00\0,\00\00\0,\00\00\0,\00\00\0,\00\00\0\r\0
\0"\0U\0p\0p\0e\0r\0B\0i\0n\0d\0"\0=\0h\0e\0x\0(\07\0)\0:\04\0e\0,\00\00\0,\06\04\0,\00\00\0,\06\09\0,\00\00\0,\07\03\0,\00\00\0,\07\05\0,\00\00\0,\06\09\0,\00\00\0,\06\0f\0,\00\00\0,\00\00\0,\00\00\0,\05\04\0,\00\00\0,\06\03\0,\00\00\0,\0\\0\r\0
\0 \0 \07\00\0,\00\00\0,\06\09\0,\00\00\0,\07\00\0,\00\00\0,\00\00\0,\00\00\0,\05\04\0,\00\00\0,\06\03\0,\00\00\0,\07\00\0,\00\00\0,\06\09\0,\00\00\0,\07\00\0,\00\00\0,\03\06\0,\00\00\0,\00\00\0,\00\00\0,\00\00\0,\00\00\0\r\0
\0"\0E\0x\0p\0o\0r\0t\0"\0=\0h\0e\0x\0(\07\0)\0:\05\0c\0,\00\00\0,\04\04\0,\00\00\0,\06\05\0,\00\00\0,\07\06\0,\00\00\0,\06\09\0,\00\00\0,\06\03\0,\00\00\0,\06\05\0,\00\00\0,\05\0c\0,\00\00\0,\07\0b\0,\00\00\0,\03\02\0,\00\00\0,\03\04\0,\0\\0\r\0
\0 \0 \00\00\0,\03\04\0,\00\00\0,\03\04\0,\00\00\0,\03\03\0,\00\00\0,\03\00\0,\00\00\0,\04\05\0,\00\00\0,\03\05\0,\00\00\0,\02\0d\0,\00\00\0,\04\06\0,\00\00\0,\03\06\0,\00\00\0,\04\02\0,\00\00\0,\03\01\0,\00\00\0,\02\0d\0,\00\00\0,\0\\0\r\0
\0 \0 \03\04\0,\00\00\0,\04\05\0,\00\00\0,\03\09\0,\00\00\0,\04\03\0,\00\00\0,\02\0d\0,\00\00\0,\03\09\0,\00\00\0,\03\00\0,\00\00\0,\03\01\0,\00\00\0,\03\01\0,\00\00\0,\02\0d\0,\00\00\0,\03\04\0,\00\00\0,\03\01\0,\00\00\0,\03\03\0,\0\\0\r\0
\0 \0 \00\00\0,\04\02\0,\00\00\0,\03\07\0,\00\00\0,\04\05\0,\00\00\0,\03\02\0,\00\00\0,\03\04\0,\00\00\0,\03\05\0,\00\00\0,\03\09\0,\00\00\0,\03\08\0,\00\00\0,\04\03\0,\00\00\0,\07\0d\0,\00\00\0,\00\00\0,\00\00\0,\00\00\0,\00\00\0\r\0
\0\r\0
\0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0]\0\r\0
\0"\0S\0e\0r\0v\0i\0c\0e\0"\0=\0"\0h\0w\0u\0s\0b\0_\0w\0w\0a\0n\0e\0c\0m\0"\0\r\0
\0\r\0
\0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0I\0n\0t\0e\0r\0f\0a\0c\0e\0s\0]\0\r\0
\0"\0U\0p\0p\0e\0r\0R\0a\0n\0g\0e\0"\0=\0"\0f\0l\0p\0p\04\0 \0a\0n\0d\0 \0f\0l\0p\0p\06\0"\0\r\0
\0"\0L\0o\0w\0e\0r\0R\0a\0n\0g\0e\0"\0=\0"\0p\0p\0i\0p\0"\0\r\0
\0\r\0
\0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0]\0\r\0
\0\r\0
\0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0d\0i\0s\0a\0b\0l\0e\0_\0a\0c\0c\0u\0m\0u\0l\0a\0t\0i\0o\0n\0_\0u\0p\0d\0a\0t\0e\0]\0\r\0
\0"\0P\0a\0r\0a\0m\0D\0e\0s\0c\0"\0=\0"\0F\0l\0a\0g\0 \0t\0o\0 \0d\0i\0s\0a\0b\0l\0e\0 \0N\0C\0M\0 \0a\0c\0c\0u\0m\0u\0l\0a\0t\0i\0o\0n\0 \0a\0u\0t\0o\0 \0u\0p\0d\0a\0t\0i\0o\0n\0"\0\r\0
\0"\0D\0e\0f\0a\0u\0l\0t\0"\0=\0"\00\0"\0\r\0
\0"\0t\0y\0p\0e\0"\0=\0"\0d\0w\0o\0r\0d\0"\0\r\0
\0\r\0
\0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0F\0l\0o\0w\0C\0o\0n\0t\0r\0o\0l\0T\0i\0m\0e\0O\0u\0t\0]\0\r\0
\0"\0P\0a\0r\0a\0m\0D\0e\0s\0c\0"\0=\0"\0F\0l\0o\0w\0 \0C\0o\0n\0t\0r\0o\0l\0 \0t\0i\0m\0e\0o\0u\0t\0 \0i\0n\0t\0e\0r\0v\0a\0l\0 \0i\0n\0 \0m\0s\0"\0\r\0
\0"\0D\0e\0f\0a\0u\0l\0t\0"\0=\0"\02\08\00\00\0"\0\r\0
\0"\0t\0y\0p\0e\0"\0=\0"\0d\0w\0o\0r\0d\0"\0\r\0
\0\r\0
\0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0F\0r\0a\0m\0e\0T\0y\0p\0e\0]\0\r\0
\0"\0P\0a\0r\0a\0m\0D\0e\0s\0c\0"\0=\0"\0F\0r\0a\0m\0e\0 \0T\0y\0p\0e\0 \0i\0n\0 \0d\0r\0i\0v\0e\0r\0-\0d\0e\0v\0i\0c\0e\0 \0c\0o\0m\0m\0u\0n\0i\0c\0a\0t\0i\0o\0n\0s\0"\0\r\0
\0"\0t\0y\0p\0e\0"\0=\0"\0e\0n\0u\0m\0"\0\r\0
\0"\0D\0e\0f\0a\0u\0l\0t\0"\0=\0"\00\0"\0\r\0
\0\r\0
\0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0F\0r\0a\0m\0e\0T\0y\0p\0e\0\\0e\0n\0u\0m\0]\0\r\0
\0"\01\0"\0=\0"\0I\0P\0"\0\r\0
\0"\00\0"\0=\0"\0E\0t\0h\0e\0r\0n\0e\0t\0"\0\r\0
\0\r\0
\0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0I\0s\0N\0t\0b\03\02\0]\0\r\0
\0"\0P\0a\0r\0a\0m\0D\0e\0s\0c\0"\0=\0"\03\02\0b\0i\0t\0 \0m\0o\0d\0e\0"\0\r\0
\0"\0D\0e\0f\0a\0u\0l\0t\0"\0=\0"\01\0"\0\r\0
\0"\0t\0y\0p\0e\0"\0=\0"\0e\0n\0u\0m\0"\0\r\0
\0\r\0
\0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0I\0s\0N\0t\0b\03\02\0\\0e\0n\0u\0m\0]\0\r\0
\0"\01\0"\0=\0"\0Y\0e\0s\0"\0\r\0
\0"\00\0"\0=\0"\0N\0o\0"\0\r\0
\0\r\0
\0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0M\0a\0x\0N\0u\0m\0O\0f\0D\0a\0t\0a\0g\0r\0a\0m\0s\0I\0n\0N\0T\0B\0]\0\r\0
\0"\0P\0a\0r\0a\0m\0D\0e\0s\0c\0"\0=\0"\0M\0a\0x\0i\0m\0u\0m\0 \0n\0u\0m\0b\0e\0r\0 \0o\0f\0 \0d\0a\0t\0a\0g\0r\0a\0m\0s\0 \0i\0n\0 \0N\0T\0B\0"\0\r\0
\0"\0D\0e\0f\0a\0u\0l\0t\0"\0=\0"\06\04\0"\0\r\0
\0"\0t\0y\0p\0e\0"\0=\0"\0d\0w\0o\0r\0d\0"\0\r\0
\0\r\0
\0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0N\0c\0m\0R\0e\0i\0n\0i\0t\0i\0a\0l\0i\0z\0e\0E\0n\0a\0b\0l\0e\0]\0\r\0
\0"\0P\0a\0r\0a\0m\0D\0e\0s\0c\0"\0=\0"\0F\0l\0a\0g\0 \0t\0o\0 \0e\0n\0a\0b\0l\0e\0 \0N\0C\0M\0 \0r\0e\0i\0n\0i\0t\0i\0a\0l\0i\0z\0e\0 \0a\0f\0t\0e\0r\0 \0r\0e\0s\0u\0m\0e\0"\0\r\0
\0"\0D\0e\0f\0a\0u\0l\0t\0"\0=\0"\01\0"\0\r\0
\0"\0t\0y\0p\0e\0"\0=\0"\0d\0w\0o\0r\0d\0"\0\r\0
\0\r\0
\0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0N\0T\0B\0I\0n\0p\0u\0t\0S\0i\0z\0e\0]\0\r\0
\0"\0P\0a\0r\0a\0m\0D\0e\0s\0c\0"\0=\0"\0N\0T\0B\0 \0i\0n\0p\0u\0t\0 \0s\0i\0z\0e\0"\0\r\0
\0"\0D\0e\0f\0a\0u\0l\0t\0"\0=\0"\00\0"\0\r\0
\0"\0t\0y\0p\0e\0"\0=\0"\0d\0w\0o\0r\0d\0"\0\r\0
\0\r\0
\0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0P\0a\0c\0k\0e\0t\0s\0A\0c\0c\0u\0m\0u\0l\0a\0t\0i\0o\0n\0T\0i\0m\0e\0o\0u\0t\0]\0\r\0
\0"\0P\0a\0r\0a\0m\0D\0e\0s\0c\0"\0=\0"\0P\0a\0c\0k\0e\0t\0s\0 \0A\0c\0c\0u\0m\0u\0l\0a\0t\0i\0o\0n\0 \0T\0i\0m\0e\0o\0u\0t\0 \0[\0u\0s\0e\0c\0]\0"\0\r\0
\0"\0D\0e\0f\0a\0u\0l\0t\0"\0=\0"\02\00\0"\0\r\0
\0"\0t\0y\0p\0e\0"\0=\0"\0d\0w\0o\0r\0d\0"\0\r\0
\0\r\0
\0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0P\0r\0o\0m\0i\0s\0c\0u\0o\0u\0s\0]\0\r\0
\0"\0P\0a\0r\0a\0m\0D\0e\0s\0c\0"\0=\0"\0S\0e\0t\0 \0t\0h\0e\0 \0p\0h\0y\0s\0i\0c\0a\0l\0 \0N\0I\0C\0 \0t\0o\0 \0p\0r\0o\0m\0i\0s\0c\0u\0o\0u\0s\0 \0m\0o\0d\0e\0"\0\r\0
\0"\0D\0e\0f\0a\0u\0l\0t\0"\0=\0"\00\0"\0\r\0
\0"\0t\0y\0p\0e\0"\0=\0"\0e\0n\0u\0m\0"\0\r\0
\0\r\0
\0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0P\0r\0o\0m\0i\0s\0c\0u\0o\0u\0s\0\\0e\0n\0u\0m\0]\0\r\0
\0"\01\0"\0=\0"\0E\0n\0a\0b\0l\0e\0"\0\r\0
\0"\00\0"\0=\0"\0D\0i\0s\0a\0b\0l\0e\0"\0\r\0
\0\r\0
\0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0W\0w\0a\0n\0M\0b\0i\0m\0E\0n\0a\0b\0l\0e\0]\0\r\0
\0"\0P\0a\0r\0a\0m\0D\0e\0s\0c\0"\0=\0"\0F\0l\0a\0g\0 \0t\0o\0 \0e\0n\0a\0b\0l\0e\0 \0W\0W\0A\0N\0 \0M\0B\0I\0M\0 \0f\0u\0n\0c\0t\0i\0o\0n\0"\0\r\0
\0"\0D\0e\0f\0a\0u\0l\0t\0"\0=\0"\00\0"\0\r\0
\0"\0t\0y\0p\0e\0"\0=\0"\0d\0w\0o\0r\0d\0"\0\r\0
\0\r\0
\0
^ permalink raw reply
* RE: Is this 32-bit NCM?
From: Eli Britstein @ 2014-12-02 7:45 UTC (permalink / raw)
To: Kevin Zhu, Enrico Mioso
Cc: Bjørn Mork, Alex Strizhevsky, Midge Shaojun Tan,
youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <547D6D7B.5090704-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
Outlook blocked the attachment. Please zip it and resend.
Thanks,
Best regards,
Eli Britstein
SW Team Leader and Project Manager
MP2xx Residential Gateways
Tel: +972-3-9764148
Mobile: +972-54-2312677
Fax: +972-3-9764040
Email: Eli.Britstein@audiocodes.com
Web: www.audiocodes.com
-----Original Message-----
From: Kevin Zhu
Sent: Tuesday, December 02, 2014 9:44
To: Enrico Mioso
Cc: Eli Britstein; Bjørn Mork; Alex Strizhevsky; Midge Shaojun Tan; youtux@gmail.com; linux-usb@vger.kernel.org; netdev@vger.kernel.org
Subject: Re: Is this 32-bit NCM?
Hi all,
Here's the registry from windows 7. Attached. One parameter that might be interesting is MaxNumOfDatagramInNTB, which is 64. I wonder if it has something to do with MaxDatagramSize. Can someone also check the registry, in case I missed something?
Regards,
Kevin
On 12/02/2014 02:49 PM, Enrico Mioso wrote:
> Can you try to look at Windows registry keys based on the INF file as
> suggested or would this be a problem for you?
> And... if you have any Huawei manutal talking about it: even device's
> ^DSFLOWRPT might be useful to some extent, but ... this is only just a
> note in case we don't find anything else.
> Regards ... and good day to all of you, Enrico
>
>
> On Tue, 2 Dec 2014, Kevin Zhu wrote:
>
> ==Date: Tue, 2 Dec 2014 07:43:24
> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
> ==To: Enrico Mioso <mrkiko.rs@gmail.com>
> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, Bjørn Mork <bjorn@mork.no>,
> == Alex Strizhevsky <alexxst@gmail.com>,
> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
> == "youtux@gmail.com" <youtux@gmail.com>,
> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
> ==Subject: Re: Is this 32-bit NCM?
> ==
> ==I also tried to define CDC_NCM_DPT_DATAGRAMS_MAX as 1 to eliminate
> the ==paddings, but it did not work either, not even DHCP.
> ==
> ==Regards,
> ==Kevin
> ==
> ==On 12/02/2014 02:32 PM, Enrico Mioso wrote:
> ==> Hi again Eli,
> ==> Hi Kevin,
> ==> Hi everyone...
> ==>
> ==> As I understand it anyway - the distinction here tends not to be
> between ==> different types of packets.
> ==> It tends to be between received and sent packet.
> ==> We are not able to generate packets that the device retains valid.
> ==> If you manually configure the IP the device would have assigned
> you via DHCP, ==> your system will start answering ARP request, saying
> that the host with IP ==> aa.bb.cc.dd is at aa:bb:cc:dd:ee (using the MC address of the dongle).
> ==> However, the other host (gateway) will never know that. Indeed,
> it'll continue ==> asking who-is at aa.bb.cc.dd ?
> ==> At least, this is the situation I observed in the test system.
> ==>
> ==>
> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote:
> ==>
> ==> ==Date: Tue, 2 Dec 2014 04:53:53
> ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> ==> ==To: Eli
> Britstein <Eli.Britstein@audiocodes.com>,
> ==> == Enrico Mioso <mrkiko.rs@gmail.com>
> ==> ==Cc: Bjørn Mork <bjorn@mork.no>, Alex Strizhevsky <alexxst@gmail.com>,
> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
> ==> == "youtux@gmail.com" <youtux@gmail.com>,
> ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
> ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
> ==> ==Subject: Re: Is this 32-bit NCM?
> ==> ==
> ==> ==Hi,
> ==> ==
> ==> ==The DHCP packets have the maximum size of dwNtbOutMaxSize=16384,
> while ==> ==the other packets are less than that. However, the DHCP
> queries are not ==> ==replied in time either, there's always some delay.
> ==> ==
> ==> ==By the way, though the device claims to support
> GET_MAX_DATAGRAM_SIZE, ==> ==but it returns error when the host sends
> this command to it. I disabled ==> ==this command in NCM driver and tried, but it's the same result.
> ==> ==
> ==> ==Regards,
> ==> ==Kevin
> ==> ==
> ==> ==On 12/02/2014 06:02 AM, Eli Britstein wrote:
> ==> ==> Hi Enrico and all,
> ==> ==>
> ==> ==> Maybe I missed something but what is the difference by the driver point of view between the dhcp discover and request (that are ok) to others (like arp, that is nok)?
> ==> ==> Maybe we can trace to compare them?
> ==> ==>
> ==> ==> Sent from my iPhone
> ==> ==>
> ==> ==>> On 1 בדצמ 2014, at 23:11, "Enrico Mioso" <mrkiko.rs@gmail.com> wrote:
> ==> ==>>
> ==> ==>> So ... I have two ideas left for now.
> ==> ==>> We know for sure the problem is in the way we TX frames, not
> the way we RX them ==> ==>> (the way we send, generate them, not the way we receive them).
> ==> ==>> Si I have two ideas, and I ask for help from the Linux-usb
> mailing list for ==> ==>> this first one.
> ==> ==>>
> ==> ==>> 1 - Does a wayexist to "replay" traffic crom a usb capture?
> ==> ==>> We might try to take the usb frames generated by Windows, and
> send them to the ==> ==>> device to see if there is any reaction. It
> should not be science fiction, I saw ==> ==>> them do that in the eciadsl old project.
> ==> ==>> 2 - The huawei ndis driver: does it work with these devices?
> ==> ==>> It should be a little bit out-dated now (at least in terms of
> dates, it might ==> ==>> work as well): the code is A LOT but, just in
> case, to see if there is any ==> ==>> chances it'll work. It remains
> to be seen in which kernels it can actually ==> ==>> compile again.
> ==> ==>>
> ==> ==>> If this works we might analyse what's happening and try to debug this out.
> ==> ==>> But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm.
> ==> ==>> Thank you.
> ==> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
> ==> ==
> ==> ==If you have received this email in error please immediately
> notify the sender and delete or destroy any copy of this message ==>
> == ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
> ==
> ==If you have received this email in error please immediately notify
> the sender and delete or destroy any copy of this message ==
________________________________
This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
^ permalink raw reply
* Out-of-bounds access in nfnetlink_bind
From: Dmitry Vyukov @ 2014-12-02 7:53 UTC (permalink / raw)
To: pablo, kaber, kadlec, David Miller, netfilter-devel, coreteam,
netdev, LKML, kasan-dev, Dmitry Chernenkov, Kostya Serebryany,
Andrey Konovalov
Hi,
I am working on Kernel AddressSanitizer, a fast memory error detector
for kernel:
https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel
Here is an error report that I got while running trinity:
==================================================================
BUG: AddressSanitizer: out of bounds access in
nfnetlink_bind+0xbf/0xe0 at addr ffffffff82eef710
Read of size 4 by task trinity-main/2533
Out-of-bounds access to the global variable 'nfnl_group2type'
[ffffffff82eef6e0-ffffffff82eef704) defined at
net/netfilter/nfnetlink.c:43:18
CPU: 0 PID: 2533 Comm: trinity-main Not tainted 3.18.0-rc1+ #44
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffffffff835173e8 ffff8800b989fd18 ffffffff82a3d66f 0000000000000007
ffff8800b989fdc0 ffff8800b989fda8 ffffffff813a3826 0000000000000012
0000000000000000 0000000100000018 0000000000000296 ffff8800b989fd88
Call Trace:
[<ffffffff813a39c1>] __asan_report_load4_noabort+0x41/0x50
mm/kasan/report.c:236
[<ffffffff824769cf>] nfnetlink_bind+0xbf/0xe0 net/netfilter/nfnetlink.c:467
[<ffffffff82469b71>] netlink_bind+0x221/0x7e0 net/netlink/af_netlink.c:1472
[<ffffffff8238bf77>] SYSC_bind+0x117/0x170 net/socket.c:1541
[<ffffffff8238dc29>] SyS_bind+0x9/0x10 net/socket.c:1527
[<ffffffff82a522a9>] system_call_fastpath+0x12/0x17
arch/x86/kernel/entry_64.S:422
Memory state around the buggy address:
ffffffff82eef480: 00 00 00 00 00 00 00 00 00 00 00 00 00 f8 f8 f8
ffffffff82eef500: f8 f8 f8 f8 00 00 00 00 f8 f8 f8 f8 00 00 00 01
ffffffff82eef580: f8 f8 f8 f8 00 00 00 00 05 f8 f8 f8 f8 f8 f8 f8
ffffffff82eef600: 00 00 04 f8 f8 f8 f8 f8 00 00 f8 f8 f8 f8 f8 f8
ffffffff82eef680: 00 00 00 00 07 f8 f8 f8 f8 f8 f8 f8 00 00 00 00
>ffffffff82eef700: 04 f8 f8 f8 f8 f8 f8 f8 00 06 f8 f8 f8 f8 f8 f8
^
ffffffff82eef780: 00 00 00 05 f8 f8 f8 f8 00 00 00 00 00 f8 f8 f8
ffffffff82eef800: f8 f8 f8 f8 00 00 00 00 02 f8 f8 f8 f8 f8 f8 f8
ffffffff82eef880: 00 00 00 00 06 f8 f8 f8 f8 f8 f8 f8 00 00 00 04
ffffffff82eef900: f8 f8 f8 f8 00 00 00 00 00 04 f8 f8 f8 f8 f8 f8
ffffffff82eef980: 00 00 00 07 f8 f8 f8 f8 00 00 00 06 f8 f8 f8 f8
==================================================================
My source is on revision f114040e3ea6e07372334ade75d1ee0
As far as I see netlink_bind just calls nfnetlink_bind with whatever
groups user has requested; nfnetlink_bind in turn do not do any checks
before indexing the global nfnl_group2type array with the group.
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Kevin Zhu @ 2014-12-02 7:53 UTC (permalink / raw)
To: Enrico Mioso
Cc: Eli Britstein, Bjørn Mork, Alex Strizhevsky,
Midge Shaojun Tan, youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <alpine.LNX.2.03.1412020747360.1921@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6494 bytes --]
reattach the registry.
Regards,
Kevin
On 12/02/2014 02:49 PM, Enrico Mioso wrote:
> Can you try to look at Windows registry keys based on the INF file as suggested
> or would this be a problem for you?
> And... if you have any Huawei manutal talking about it: even device's
> ^DSFLOWRPT
> might be useful to some extent, but ... this is only just a note in case we
> don't find anything else.
> Regards ... and good day to all of you,
> Enrico
>
>
> On Tue, 2 Dec 2014, Kevin Zhu wrote:
>
> ==Date: Tue, 2 Dec 2014 07:43:24
> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
> ==To: Enrico Mioso <mrkiko.rs@gmail.com>
> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, Bjørn Mork <bjorn@mork.no>,
> == Alex Strizhevsky <alexxst@gmail.com>,
> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
> == "youtux@gmail.com" <youtux@gmail.com>,
> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
> ==Subject: Re: Is this 32-bit NCM?
> ==
> ==I also tried to define CDC_NCM_DPT_DATAGRAMS_MAX as 1 to eliminate the
> ==paddings, but it did not work either, not even DHCP.
> ==
> ==Regards,
> ==Kevin
> ==
> ==On 12/02/2014 02:32 PM, Enrico Mioso wrote:
> ==> Hi again Eli,
> ==> Hi Kevin,
> ==> Hi everyone...
> ==>
> ==> As I understand it anyway - the distinction here tends not to be between
> ==> different types of packets.
> ==> It tends to be between received and sent packet.
> ==> We are not able to generate packets that the device retains valid.
> ==> If you manually configure the IP the device would have assigned you via DHCP,
> ==> your system will start answering ARP request, saying that the host with IP
> ==> aa.bb.cc.dd is at aa:bb:cc:dd:ee (using the MC address of the dongle).
> ==> However, the other host (gateway) will never know that. Indeed, it'll continue
> ==> asking who-is at aa.bb.cc.dd ?
> ==> At least, this is the situation I observed in the test system.
> ==>
> ==>
> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote:
> ==>
> ==> ==Date: Tue, 2 Dec 2014 04:53:53
> ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
> ==> ==To: Eli Britstein <Eli.Britstein@audiocodes.com>,
> ==> == Enrico Mioso <mrkiko.rs@gmail.com>
> ==> ==Cc: Bjørn Mork <bjorn@mork.no>, Alex Strizhevsky <alexxst@gmail.com>,
> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
> ==> == "youtux@gmail.com" <youtux@gmail.com>,
> ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
> ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
> ==> ==Subject: Re: Is this 32-bit NCM?
> ==> ==
> ==> ==Hi,
> ==> ==
> ==> ==The DHCP packets have the maximum size of dwNtbOutMaxSize=16384, while
> ==> ==the other packets are less than that. However, the DHCP queries are not
> ==> ==replied in time either, there's always some delay.
> ==> ==
> ==> ==By the way, though the device claims to support GET_MAX_DATAGRAM_SIZE,
> ==> ==but it returns error when the host sends this command to it. I disabled
> ==> ==this command in NCM driver and tried, but it's the same result.
> ==> ==
> ==> ==Regards,
> ==> ==Kevin
> ==> ==
> ==> ==On 12/02/2014 06:02 AM, Eli Britstein wrote:
> ==> ==> Hi Enrico and all,
> ==> ==>
> ==> ==> Maybe I missed something but what is the difference by the driver point of view between the dhcp discover and request (that are ok) to others (like arp, that is nok)?
> ==> ==> Maybe we can trace to compare them?
> ==> ==>
> ==> ==> Sent from my iPhone
> ==> ==>
> ==> ==>> On 1 בדצמ 2014, at 23:11, "Enrico Mioso" <mrkiko.rs@gmail.com> wrote:
> ==> ==>>
> ==> ==>> So ... I have two ideas left for now.
> ==> ==>> We know for sure the problem is in the way we TX frames, not the way we RX them
> ==> ==>> (the way we send, generate them, not the way we receive them).
> ==> ==>> Si I have two ideas, and I ask for help from the Linux-usb mailing list for
> ==> ==>> this first one.
> ==> ==>>
> ==> ==>> 1 - Does a wayexist to "replay" traffic crom a usb capture?
> ==> ==>> We might try to take the usb frames generated by Windows, and send them to the
> ==> ==>> device to see if there is any reaction. It should not be science fiction, I saw
> ==> ==>> them do that in the eciadsl old project.
> ==> ==>> 2 - The huawei ndis driver: does it work with these devices?
> ==> ==>> It should be a little bit out-dated now (at least in terms of dates, it might
> ==> ==>> work as well): the code is A LOT but, just in case, to see if there is any
> ==> ==>> chances it'll work. It remains to be seen in which kernels it can actually
> ==> ==>> compile again.
> ==> ==>>
> ==> ==>> If this works we might analyse what's happening and try to debug this out.
> ==> ==>> But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm.
> ==> ==>> Thank you.
> ==> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
> ==> ==
> ==> ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
> ==> ==
> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
> ==
> ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
> ==
This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
[-- Attachment #2: e3372.reg.gz --]
[-- Type: application/x-gzip, Size: 1719 bytes --]
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Kevin Zhu @ 2014-12-02 8:03 UTC (permalink / raw)
To: Eli Britstein, Enrico Mioso
Cc: Bjørn Mork, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <E0C3DF2A36210C42B1AB4626A0E10F1FD949424C@aclmbx01.corp.audiocodes.com>
Below is the content of the INF file oem54.inf.
; Copyright (c) 2010,2011 Huawei Incorporated
; Manufacturer: Huawei Incorporated
;
; CDC ECM & NCM driver
;
[Version]
Signature="$WINDOWS NT$"
Class=Net
ClassGUID={4d36e972-e325-11ce-bfc1-08002be10318}
Provider=%Mfg%
DriverVer=04/14/2014,1.0.13.0
CatalogFile=ew_wwanecm.cat
[Manufacturer]
%Mfg% = DeviceList,NTx86,NTamd64
[SourceDisksNames]
1 = %ew_wwanecm.DiskName%,,,""
[SourceDisksFiles]
ew_wwanecm.sys = 1,,
; For Win2K
[DeviceList]
%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
USB\VID_12D1&Subclass_03&Prot_16
%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
USB\VID_12D1&Subclass_03&Prot_46
%PNP21_NetworkDesc% = ew_wwanecm.ndi,
USB\VID_12D1&Subclass_03&Prot_76
%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
USB\VID_12D1&Subclass_03&Prot_07
%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
USB\VID_12D1&Subclass_03&Prot_37
%PNP21_NetworkDesc% = ew_wwanecm.ndi,
USB\VID_12D1&Subclass_03&Prot_67
%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
USB\VID_12D1&Subclass_03&Prot_11
; for logo test
%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
; For WinXP and later
[DeviceList.NTx86]
%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
USB\VID_12D1&Subclass_03&Prot_16
%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
USB\VID_12D1&Subclass_03&Prot_46
%PNP21_NetworkDesc% = ew_wwanecm.ndi,
USB\VID_12D1&Subclass_03&Prot_76
%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
USB\VID_12D1&Subclass_03&Prot_07
%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
USB\VID_12D1&Subclass_03&Prot_37
%PNP21_NetworkDesc% = ew_wwanecm.ndi,
USB\VID_12D1&Subclass_03&Prot_67
%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
USB\VID_12D1&Subclass_03&Prot_11
; for logo test
%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
; For XP and later x64
[DeviceList.NTamd64]
%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
USB\VID_12D1&Subclass_03&Prot_16
%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
USB\VID_12D1&Subclass_03&Prot_46
%PNP21_NetworkDesc% = ew_wwanecm.ndi,
USB\VID_12D1&Subclass_03&Prot_76
%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
USB\VID_12D1&Subclass_03&Prot_07
%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
USB\VID_12D1&Subclass_03&Prot_37
%PNP21_NetworkDesc% = ew_wwanecm.ndi,
USB\VID_12D1&Subclass_03&Prot_67
%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
USB\VID_12D1&Subclass_03&Prot_11
; for logo test
%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
;-------------------------------------------------------------------------------
; Virtual Ethernet Adapter
;
[ew_wwanecm.ndi]
*IfType = 243 ; IF_TYPE_WWANPP
*MediaType = 9; NdisMediumWirelessWan
*PhysicalMediaType = 8 ; NdisPhysicalMediumWirelessWan
EnableDhcp = 0 ; DHCP Disabled
Characteristics = 0x84 ; NCF_HAS_UI | NCF_PHYSICAL
BusType = 15 ; if you specify NCF_PHYSICAL, you must specify
bustype
AddReg = ew_wwanecm.Reg, ParamsPromiscuous, ParamsFrameType,
ParamsIsNtb32, ParamsNTBInputSize, ParamsPacketsAccumulationTimeout,
ParamsMaxNumOfDatagramsInNTB, FlowControlTimeOut,
DisableAccumulationUpdate, WwanMbimEnable, NcmReinitializeEnable
CopyFiles = ew_wwanecm.CopyFiles
[WWAN_AddReg]
HKR,, Platform,0x00010001,0x3
HKR,, WWAN,0x00010001,0x1
HKR,, "SelectiveSuspendIdleTime", 0x00010001, 0x05
[ew_wwanecm.ndi.Services]
AddService = %ServiceName%, 2, ew_wwanecm.Service, ew_wwanecm.EventLog
[ew_wwanecm.ndi.HW]
AddReg = WWAN_AddReg
;-----------------------------------------------------------------------------
;
[ew_wwanecm.Reg]
HKR, , BusNumber, 0, "0"
HKR, , MPRadioState, 0x00010001,
0x00000001 ;RadioState
HKR, Ndi, Service, 0, "hwusb_wwanecm"
HKR, Ndi\Interfaces, UpperRange, 0, "flpp4" and
"flpp6"
HKR, Ndi\Interfaces, LowerRange, 0, "ppip"
[ParamsPromiscuous]
;
; Should the physical NIC be set to Promiscuous mode
;
HKR, Ndi\Params\Promiscuous, ParamDesc, , %Promiscuous%
HKR, Ndi\Params\Promiscuous, Default, ,"0"
HKR, Ndi\Params\Promiscuous, type, , enum
HKR, Ndi\Params\Promiscuous\enum,"1", , %Promiscuous_Enable%
HKR, Ndi\Params\Promiscuous\enum,"0", , %Promiscuous_Disable%
[ParamsFrameType]
HKR, Ndi\Params\FrameType, ParamDesc, 0, %FrameType%
HKR, Ndi\Params\FrameType, type, 0, enum
HKR, Ndi\Params\FrameType, Default, 0, "0"
HKR, Ndi\Params\FrameType\enum,"1", 0, %FrameType_IP%
HKR, Ndi\Params\FrameType\enum,"0", 0, %FrameType_Ethernet%
[ParamsIsNtb32]
HKR, Ndi\Params\IsNtb32, ParamDesc, , %IsNtb32%
HKR, Ndi\Params\IsNtb32, Default, , "1"
HKR, Ndi\Params\IsNtb32, type, , enum
HKR, Ndi\Params\IsNtb32\enum, "1", , "Yes"
HKR, Ndi\Params\IsNtb32\enum, "0", , "No"
[ParamsNTBInputSize]
HKR, Ndi\Params\NTBInputSize, ParamDesc, , %NTBInputSize%
; If the following size is larger than the maximum allowed by the
device, the
; maximum value is used. 0 means to use the maximum allowed value of the
device.
HKR, Ndi\Params\NTBInputSize, Default, , "0"
HKR, Ndi\Params\NTBInputSize, type, , dword
[ParamsPacketsAccumulationTimeout]
HKR, Ndi\Params\PacketsAccumulationTimeout, ParamDesc, ,
%PacketsAccumulationTimeout%
; Unit of PacketsAccumulationTimeout is usecs. Default value is 20 us.
HKR, Ndi\Params\PacketsAccumulationTimeout, Default, , "20"
HKR, Ndi\Params\PacketsAccumulationTimeout, type, , dword
[ParamsMaxNumOfDatagramsInNTB]
HKR, Ndi\Params\MaxNumOfDatagramsInNTB, ParamDesc, ,
%MaxNumOfDatagramsInNTB%
HKR, Ndi\Params\MaxNumOfDatagramsInNTB, Default, , "64"
HKR, Ndi\Params\MaxNumOfDatagramsInNTB, type, , dword
[FlowControlTimeOut]
HKR, Ndi\Params\FlowControlTimeOut, ParamDesc, , %FlowControlTimeout%
HKR, Ndi\Params\FlowControlTimeOut, Default, , "2800"
HKR, Ndi\Params\FlowControlTimeOut, type, , dword
[DisableAccumulationUpdate]
HKR, Ndi\Params\disable_accumulation_update, ParamDesc, ,
%DisableAccumulationUpdate%
HKR, Ndi\Params\disable_accumulation_update, Default, , "0"
HKR, Ndi\Params\disable_accumulation_update, type, , dword
[WwanMbimEnable]
HKR, Ndi\Params\WwanMbimEnable, ParamDesc, , %WwanMbimEnable%
HKR, Ndi\Params\WwanMbimEnable, Default, , "0"
HKR, Ndi\Params\WwanMbimEnable, type, , dword
[NcmReinitializeEnable]
HKR, Ndi\Params\NcmReinitializeEnable, ParamDesc, , %NcmReinitializeEnable%
HKR, Ndi\Params\NcmReinitializeEnable, Default, , "1"
HKR, Ndi\Params\NcmReinitializeEnable, type, , dword
;-----------------------------------------------------------------------------
; DestinationDirs
;
[DestinationDirs]
ew_wwanecm.CopyFiles = 12
[ew_wwanecm.CopyFiles]
ew_wwanecm.sys,,,0x6 ;COPYFLG_NOSKIP | COPYFLG_NOVERSIONCHECK
;-----------------------------------------------------------------------------
; Driver and Service Section
;
[ew_wwanecm.Service]
ServiceType = 1 ;%SERVICE_KERNEL_DRIVER%
StartType = 3 ;%SERVICE_DEMAND_START%
ErrorControl = 1 ;%SERVICE_ERROR_NORMAL%
ServiceBinary = %12%\ew_wwanecm.sys
LoadOrderGroup = NDIS
AddReg = ew_wwanecm.Service.Reg
[ew_wwanecm.Service.Reg]
HKR, , TextModeFlags, 0x00010001, 0x0001
HKR, Parameters, DebugLevel, 0x00010001, 1
HKR, Parameters, WwanLogoTestOn, 0x00010001, 0
[ew_wwanecm.EventLog]
AddReg = ew_wwanecm.AddEventLog.Reg
[ew_wwanecm.AddEventLog.Reg]
HKR, , EventMessageFile, 0x00020000, "%%SystemRoot%%\System32\netevent.dll"
HKR, , TypesSupported, 0x00010001, 7
;-----------------------------------------------------------------------------
; Localizable Strings
;
[Strings]
Mfg = "HUAWEI"
HUAWEI_NDISDeviceDesc = "HUAWEI Mobile Connect - Network Adapter"
;PNP2.1 Device descriptor
PNP21_HW_3G_NetworkDesc = "HUAWEI Mobile Connect - 3G Network Card"
PNP21_HW_NetworkDesc = "HUAWEI Mobile Connect - Network Card"
PNP21_NetworkDesc = "Mobile Connect - Network Card"
PNP21_VDF_NetworkDesc = "Vodafone Mobile Broadband Network Adapter
(Huawei)"
ew_wwanecm.DiskName = "DriverCore Installation Disk"
Promiscuous = "Set the physical NIC to promiscuous mode"
Promiscuous_Disable = "Disable"
ServiceName = "hwusb_wwanecm"
Promiscuous_Enable = "Enable"
FrameType = "Frame Type in driver-device communications"
FrameType_Ethernet = "Ethernet"
FrameType_IP = "IP"
IsNtb32 = "32bit mode"
NTBInputSize = "NTB input size"
PacketsAccumulationTimeout = "Packets Accumulation Timeout [usec]"
MaxNumOfDatagramsInNTB = "Maximum number of datagrams in NTB"
FlowControlTimeout = "Flow Control timeout interval in ms"
DisableAccumulationUpdate = "Flag to disable NCM accumulation auto
updation"
WwanMbimEnable = "Flag to enable WWAN MBIM function"
NcmReinitializeEnable = "Flag to enable NCM reinitialize after resume"
Regards,
Kevin
On 12/02/2014 03:45 PM, Eli Britstein wrote:
> Outlook blocked the attachment. Please zip it and resend.
>
> Thanks,
> Best regards,
>
> Eli Britstein
> SW Team Leader and Project Manager
> MP2xx Residential Gateways
>
> Tel: +972-3-9764148
> Mobile: +972-54-2312677
> Fax: +972-3-9764040
> Email: Eli.Britstein@audiocodes.com
> Web: www.audiocodes.com
>
>
>
> -----Original Message-----
> From: Kevin Zhu
> Sent: Tuesday, December 02, 2014 9:44
> To: Enrico Mioso
> Cc: Eli Britstein; Bjørn Mork; Alex Strizhevsky; Midge Shaojun Tan; youtux@gmail.com; linux-usb@vger.kernel.org; netdev@vger.kernel.org
> Subject: Re: Is this 32-bit NCM?
>
> Hi all,
>
> Here's the registry from windows 7. Attached. One parameter that might be interesting is MaxNumOfDatagramInNTB, which is 64. I wonder if it has something to do with MaxDatagramSize. Can someone also check the registry, in case I missed something?
>
> Regards,
> Kevin
>
> On 12/02/2014 02:49 PM, Enrico Mioso wrote:
>> Can you try to look at Windows registry keys based on the INF file as
>> suggested or would this be a problem for you?
>> And... if you have any Huawei manutal talking about it: even device's
>> ^DSFLOWRPT might be useful to some extent, but ... this is only just a
>> note in case we don't find anything else.
>> Regards ... and good day to all of you, Enrico
>>
>>
>> On Tue, 2 Dec 2014, Kevin Zhu wrote:
>>
>> ==Date: Tue, 2 Dec 2014 07:43:24
>> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
>> ==To: Enrico Mioso <mrkiko.rs@gmail.com>
>> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, Bjørn Mork <bjorn@mork.no>,
>> == Alex Strizhevsky <alexxst@gmail.com>,
>> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>> == "youtux@gmail.com" <youtux@gmail.com>,
>> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
>> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
>> ==Subject: Re: Is this 32-bit NCM?
>> ==
>> ==I also tried to define CDC_NCM_DPT_DATAGRAMS_MAX as 1 to eliminate
>> the ==paddings, but it did not work either, not even DHCP.
>> ==
>> ==Regards,
>> ==Kevin
>> ==
>> ==On 12/02/2014 02:32 PM, Enrico Mioso wrote:
>> ==> Hi again Eli,
>> ==> Hi Kevin,
>> ==> Hi everyone...
>> ==>
>> ==> As I understand it anyway - the distinction here tends not to be
>> between ==> different types of packets.
>> ==> It tends to be between received and sent packet.
>> ==> We are not able to generate packets that the device retains valid.
>> ==> If you manually configure the IP the device would have assigned
>> you via DHCP, ==> your system will start answering ARP request, saying
>> that the host with IP ==> aa.bb.cc.dd is at aa:bb:cc:dd:ee (using the MC address of the dongle).
>> ==> However, the other host (gateway) will never know that. Indeed,
>> it'll continue ==> asking who-is at aa.bb.cc.dd ?
>> ==> At least, this is the situation I observed in the test system.
>> ==>
>> ==>
>> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote:
>> ==>
>> ==> ==Date: Tue, 2 Dec 2014 04:53:53
>> ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> ==> ==To: Eli
>> Britstein <Eli.Britstein@audiocodes.com>,
>> ==> == Enrico Mioso <mrkiko.rs@gmail.com>
>> ==> ==Cc: Bjørn Mork <bjorn@mork.no>, Alex Strizhevsky <alexxst@gmail.com>,
>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>> ==> == "youtux@gmail.com" <youtux@gmail.com>,
>> ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
>> ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
>> ==> ==Subject: Re: Is this 32-bit NCM?
>> ==> ==
>> ==> ==Hi,
>> ==> ==
>> ==> ==The DHCP packets have the maximum size of dwNtbOutMaxSize=16384,
>> while ==> ==the other packets are less than that. However, the DHCP
>> queries are not ==> ==replied in time either, there's always some delay.
>> ==> ==
>> ==> ==By the way, though the device claims to support
>> GET_MAX_DATAGRAM_SIZE, ==> ==but it returns error when the host sends
>> this command to it. I disabled ==> ==this command in NCM driver and tried, but it's the same result.
>> ==> ==
>> ==> ==Regards,
>> ==> ==Kevin
>> ==> ==
>> ==> ==On 12/02/2014 06:02 AM, Eli Britstein wrote:
>> ==> ==> Hi Enrico and all,
>> ==> ==>
>> ==> ==> Maybe I missed something but what is the difference by the driver point of view between the dhcp discover and request (that are ok) to others (like arp, that is nok)?
>> ==> ==> Maybe we can trace to compare them?
>> ==> ==>
>> ==> ==> Sent from my iPhone
>> ==> ==>
>> ==> ==>> On 1 בדצמ 2014, at 23:11, "Enrico Mioso" <mrkiko.rs@gmail.com> wrote:
>> ==> ==>>
>> ==> ==>> So ... I have two ideas left for now.
>> ==> ==>> We know for sure the problem is in the way we TX frames, not
>> the way we RX them ==> ==>> (the way we send, generate them, not the way we receive them).
>> ==> ==>> Si I have two ideas, and I ask for help from the Linux-usb
>> mailing list for ==> ==>> this first one.
>> ==> ==>>
>> ==> ==>> 1 - Does a wayexist to "replay" traffic crom a usb capture?
>> ==> ==>> We might try to take the usb frames generated by Windows, and
>> send them to the ==> ==>> device to see if there is any reaction. It
>> should not be science fiction, I saw ==> ==>> them do that in the eciadsl old project.
>> ==> ==>> 2 - The huawei ndis driver: does it work with these devices?
>> ==> ==>> It should be a little bit out-dated now (at least in terms of
>> dates, it might ==> ==>> work as well): the code is A LOT but, just in
>> case, to see if there is any ==> ==>> chances it'll work. It remains
>> to be seen in which kernels it can actually ==> ==>> compile again.
>> ==> ==>>
>> ==> ==>> If this works we might analyse what's happening and try to debug this out.
>> ==> ==>> But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm.
>> ==> ==>> Thank you.
>> ==> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
>> ==> ==
>> ==> ==If you have received this email in error please immediately
>> notify the sender and delete or destroy any copy of this message ==>
>> == ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
>> ==
>> ==If you have received this email in error please immediately notify
>> the sender and delete or destroy any copy of this message ==
>
This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
^ permalink raw reply
* Re: [PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
From: Jason Wang @ 2014-12-02 8:07 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: pagupta, netdev, davem, linux-kernel, virtualization
In-Reply-To: <1417490120.4405.2@smtp.corp.redhat.com>
On Tue, Dec 2, 2014 at 11:15 AM, Jason Wang <jasowang@redhat.com> wrote:
>
>
> On Mon, Dec 1, 2014 at 6:42 PM, Michael S. Tsirkin <mst@redhat.com>
> wrote:
>> On Mon, Dec 01, 2014 at 06:17:03PM +0800, Jason Wang wrote:
>>> Hello:
>>> We used to orphan packets before transmission for virtio-net.
>>> This breaks
>>> socket accounting and can lead serveral functions won't work, e.g:
>>> - Byte Queue Limit depends on tx completion nofication to work.
>>> - Packet Generator depends on tx completion nofication for the last
>>> transmitted packet to complete.
>>> - TCP Small Queue depends on proper accounting of sk_wmem_alloc to
>>> work.
>>> This series tries to solve the issue by enabling tx interrupts.
>>> To minize
>>> the performance impacts of this, several optimizations were used:
>>> - In guest side, virtqueue_enable_cb_delayed() was used to delay
>>> the tx
>>> interrupt untile 3/4 pending packets were sent.
>>> - In host side, interrupt coalescing were used to reduce tx
>>> interrupts.
>>> Performance test results[1] (tx-frames 16 tx-usecs 16) shows:
>>> - For guest receiving. No obvious regression on throughput were
>>> noticed. More cpu utilization were noticed in few cases.
>>> - For guest transmission. Very huge improvement on througput for
>>> small
>>> packet transmission were noticed. This is expected since TSQ and
>>> other
>>> optimization for small packet transmission work after tx
>>> interrupt. But
>>> will use more cpu for large packets.
>>> - For TCP_RR, regression (10% on transaction rate and cpu
>>> utilization) were
>>> found. Tx interrupt won't help but cause overhead in this case.
>>> Using
>>> more aggressive coalescing parameters may help to reduce the
>>> regression.
>>
>> OK, you do have posted coalescing patches - does it help any?
>
> Helps a lot.
>
> For RX, it saves about 5% - 10% cpu. (reduce 60%-90% tx intrs)
> For small packet TX, it increases 33% - 245% throughput. (reduce
> about 60% inters)
> For TCP_RR, it increase the 3%-10% trans.rate. (reduce 40%-80% tx
> intrs)
>
>>
>> I'm not sure the regression is due to interrupts.
>> It would make sense for CPU but why would it
>> hurt transaction rate?
>
> Anyway guest need to take some cycles to handle tx interrupts.
> And transaction rate does increase if we coalesces more tx
> interurpts.
>>
>>
>> It's possible that we are deferring kicks too much due to BQL.
>>
>> As an experiment: do we get any of it back if we do
>> - if (kick || netif_xmit_stopped(txq))
>> - virtqueue_kick(sq->vq);
>> + virtqueue_kick(sq->vq);
>> ?
>
>
> I will try, but during TCP_RR, at most 1 packets were pending,
> I suspect if BQL can help in this case.
Looks like this helps a lot in multiple sessions of TCP_RR.
How about move the BQL patch out of this series?
Let's first converge tx interrupt and then introduce it?
(e.g with kicking after queuing X bytes?)
>
>>
>>
>> If yes, we can just kick e.g. periodically, e.g. after queueing each
>> X bytes.
>
> Okay, let me try to see if this help.
>>
>>> Changes from RFC V3:
>>> - Don't free tx packets in ndo_start_xmit()
>>> - Add interrupt coalescing support for virtio-net
>>> Changes from RFC v2:
>>> - clean up code, address issues raised by Jason
>>> Changes from RFC v1:
>>> - address comments by Jason Wang, use delayed cb everywhere
>>> - rebased Jason's patch on top of mine and include it (with some
>>> tweaks)
>>> Please reivew. Comments were more than welcomed.
>>> [1] Performance Test result:
>>> Environment:
>>> - Two Intel(R) Xeon(R) CPU E5620 @ 2.40GHz machines connected back
>>> to back
>>> with 82599ES cards.
>>> - Both host and guest were net-next.git plus the patch
>>> - Coalescing parameters for the card:
>>> Adaptive RX: off TX: off
>>> rx-usecs: 1
>>> rx-frames: 0
>>> tx-usecs: 0
>>> tx-frames: 0
>>> - Vhost_net was enabled and zerocopy was disabled
>>> - Tests was done by netperf-2.6
>>> - Guest has 2 vcpus with single queue virtio-net
>>> Results:
>>> - Numbers of square brackets are whose significance is grater than
>>> 95%
>>> Guest RX:
>>> size/sessions/+throughput/+cpu/+per_cpu_throughput/
>>> 64/1/+2.0326/[+6.2807%]/-3.9970%/
>>> 64/2/-0.2104%/[+3.2012%]/[-3.3058%]/
>>> 64/4/+1.5956%/+2.2451%/-0.6353%/
>>> 64/8/+1.1732%/+3.5123%/-2.2598%/
>>> 256/1/+3.7619%/[+5.8117%]/-1.9372%/
>>> 256/2/-0.0661%/[+3.2511%]/-3.2127%/
>>> 256/4/+1.1435%/[-8.1842%]/[+10.1591%]/
>>> 256/8/[+2.2447%]/[+6.2044%]/[-3.7283%]/
>>> 1024/1/+9.1479%/[+12.0997%]/[-2.6332%]/
>>> 1024/2/[-17.3341%]/[+0.0000%]/[-17.3341%]/
>>> 1024/4/[-0.6284%]/-1.0376%/+0.4135%/
>>> 1024/8/+1.1444%/-1.6069%/+2.7961%/
>>> 4096/1/+0.0401%/-0.5993%/+0.6433%/
>>> 4096/2/[-0.5894%]/-2.2071%/+1.6542%/
>>> 4096/4/[-0.5560%]/-1.4969%/+0.9553%/
>>> 4096/8/-0.3362%/+2.7086%/-2.9645%/
>>> 16384/1/-0.0285%/+0.7247%/-0.7478%/
>>> 16384/2/-0.5286%/+0.3287%/-0.8545%/
>>> 16384/4/-0.3297%/-2.0543%/+1.7608%/
>>> 16384/8/+1.0932%/+4.0253%/-2.8187%/
>>> 65535/1/+0.0003%/-0.1502%/+0.1508%/
>>> 65535/2/[-0.6065%]/+0.2309%/-0.8355%/
>>> 65535/4/[-0.6861%]/[+3.9451%]/[-4.4554%]/
>>> 65535/8/+1.8359%/+3.1590%/-1.2825%/
>>> Guest RX:
>>> size/sessions/+throughput/+cpu/+per_cpu_throughput/
>>> 64/1/[+65.0961%]/[-8.6807%]/[+80.7900%]/
>>> 64/2/[+6.0288%]/[-2.2823%]/[+8.5052%]/
>>> 64/4/[+5.9038%]/[-2.1834%]/[+8.2677%]/
>>> 64/8/[+5.4154%]/[-2.1804%]/[+7.7651%]/
>>> 256/1/[+184.6462%]/[+4.8906%]/[+171.3742%]/
>>> 256/2/[+46.0731%]/[-8.9626%]/[+60.4539%]/
>>> 256/4/[+45.8547%]/[-8.3027%]/[+59.0612%]/
>>> 256/8/[+45.3486%]/[-8.4024%]/[+58.6817%]/
>>> 1024/1/[+432.5372%]/[+3.9566%]/[+412.2689%]/
>>> 1024/2/[-1.4207%]/[-23.6426%]/[+29.1025%]/
>>> 1024/4/-0.1003%/[-13.6416%]/[+15.6804%]/
>>> 1024/8/[+0.2200%]/[+2.0634%]/[-1.8061%]/
>>> 4096/1/[+18.4835%]/[-46.1508%]/[+120.0283%]/
>>> 4096/2/+0.1770%/[-26.2780%]/[+35.8848%]/
>>> 4096/4/-0.1012%/-0.7353%/+0.6388%/
>>> 4096/8/-0.6091%/+1.4159%/-1.9968%/
>>> 16384/1/-0.0424%/[+11.9373%]/[-10.7021%]/
>>> 16384/2/+0.0482%/+2.4685%/-2.3620%/
>>> 16384/4/+0.0840%/[+5.3587%]/[-5.0064%]/
>>> 16384/8/+0.0048%/[+5.0176%]/[-4.7733%]/
>>> 65535/1/-0.0095%/[+10.9408%]/[-9.8705%]/
>>> 65535/2/+0.1515%/[+8.1709%]/[-7.4137%]/
>>> 65535/4/+0.0203%/[+5.4316%]/[-5.1325%]/
>>> 65535/8/+0.1427%/[+6.2753%]/[-5.7705%]/
>>> size/sessions/+trans.rate/+cpu/+per_cpu_trans.rate/
>>> 64/1/+0.2346%/[+11.5080%]/[-10.1099%]/
>>> 64/25/[-10.7893%]/-0.5791%/[-10.2697%]/
>>> 64/50/[-11.5997%]/-0.3429%/[-11.2956%]/
>>> 256/1/+0.7219%/[+13.2374%]/[-11.0524%]/
>>> 256/25/-6.9567%/+0.8887%/[-7.7763%]/
>>> 256/50/[-4.8814%]/-0.0338%/[-4.8492%]/
>>> 4096/1/-1.6061%/-0.7561%/-0.8565%/
>>> 4096/25/[+2.2120%]/[+1.0839%]/+1.1161%/
>>> 4096/50/[+5.6180%]/[+3.2116%]/[+2.3315%]/
>>> Jason Wang (4):
>>> virtio_net: enable tx interrupt
>>> virtio-net: optimize free_old_xmit_skbs stats
>>> virtio-net: add basic interrupt coalescing support
>>> vhost_net: interrupt coalescing support
>>> Michael S. Tsirkin (1):
>>> virtio_net: bql
>>> drivers/net/virtio_net.c | 211
>>> ++++++++++++++++++++++++++++++++--------
>>> drivers/vhost/net.c | 200
>>> +++++++++++++++++++++++++++++++++++--
>>> include/uapi/linux/vhost.h | 12 +++
>>> include/uapi/linux/virtio_net.h | 12 +++
>>> 4 files changed, 383 insertions(+), 52 deletions(-)
>>> -- 1.8.3.1
>
> --
> 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
^ permalink raw reply
* Re: Out-of-bounds access in nfnetlink_bind
From: Andrey Ryabinin @ 2014-12-02 8:20 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: pablo, kaber, kadlec, David Miller, netfilter-devel, coreteam,
netdev@vger.kernel.org, LKML, kasan-dev, Dmitry Chernenkov,
Kostya Serebryany, Andrey Konovalov
In-Reply-To: <CACT4Y+bZu5UHu90F8wWqckcE13D5H2LDexna6vVEMBy+X4RiZw@mail.gmail.com>
2014-12-02 10:53 GMT+03:00 Dmitry Vyukov <dvyukov@google.com>:
> Hi,
>
> I am working on Kernel AddressSanitizer, a fast memory error detector
> for kernel:
> https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel
>
> Here is an error report that I got while running trinity:
>
> ==================================================================
> BUG: AddressSanitizer: out of bounds access in
> nfnetlink_bind+0xbf/0xe0 at addr ffffffff82eef710
> Read of size 4 by task trinity-main/2533
> Out-of-bounds access to the global variable 'nfnl_group2type'
> [ffffffff82eef6e0-ffffffff82eef704) defined at
> net/netfilter/nfnetlink.c:43:18
> CPU: 0 PID: 2533 Comm: trinity-main Not tainted 3.18.0-rc1+ #44
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> ffffffff835173e8 ffff8800b989fd18 ffffffff82a3d66f 0000000000000007
> ffff8800b989fdc0 ffff8800b989fda8 ffffffff813a3826 0000000000000012
> 0000000000000000 0000000100000018 0000000000000296 ffff8800b989fd88
> Call Trace:
> [<ffffffff813a39c1>] __asan_report_load4_noabort+0x41/0x50
> mm/kasan/report.c:236
> [<ffffffff824769cf>] nfnetlink_bind+0xbf/0xe0 net/netfilter/nfnetlink.c:467
> [<ffffffff82469b71>] netlink_bind+0x221/0x7e0 net/netlink/af_netlink.c:1472
> [<ffffffff8238bf77>] SYSC_bind+0x117/0x170 net/socket.c:1541
> [<ffffffff8238dc29>] SyS_bind+0x9/0x10 net/socket.c:1527
> [<ffffffff82a522a9>] system_call_fastpath+0x12/0x17
> arch/x86/kernel/entry_64.S:422
> Memory state around the buggy address:
> ffffffff82eef480: 00 00 00 00 00 00 00 00 00 00 00 00 00 f8 f8 f8
> ffffffff82eef500: f8 f8 f8 f8 00 00 00 00 f8 f8 f8 f8 00 00 00 01
> ffffffff82eef580: f8 f8 f8 f8 00 00 00 00 05 f8 f8 f8 f8 f8 f8 f8
> ffffffff82eef600: 00 00 04 f8 f8 f8 f8 f8 00 00 f8 f8 f8 f8 f8 f8
> ffffffff82eef680: 00 00 00 00 07 f8 f8 f8 f8 f8 f8 f8 00 00 00 00
>>ffffffff82eef700: 04 f8 f8 f8 f8 f8 f8 f8 00 06 f8 f8 f8 f8 f8 f8
> ^
> ffffffff82eef780: 00 00 00 05 f8 f8 f8 f8 00 00 00 00 00 f8 f8 f8
> ffffffff82eef800: f8 f8 f8 f8 00 00 00 00 02 f8 f8 f8 f8 f8 f8 f8
> ffffffff82eef880: 00 00 00 00 06 f8 f8 f8 f8 f8 f8 f8 00 00 00 04
> ffffffff82eef900: f8 f8 f8 f8 00 00 00 00 00 04 f8 f8 f8 f8 f8 f8
> ffffffff82eef980: 00 00 00 07 f8 f8 f8 f8 00 00 00 06 f8 f8 f8 f8
> ==================================================================
>
> My source is on revision f114040e3ea6e07372334ade75d1ee0
>
> As far as I see netlink_bind just calls nfnetlink_bind with whatever
> groups user has requested; nfnetlink_bind in turn do not do any checks
> before indexing the global nfnl_group2type array with the group.
I've reported this few weeks ago: https://lkml.org/lkml/2014/11/13/65
^ permalink raw reply
* [PATCH net-next 0/2] r8169:change hardware setting
From: Chunhao Lin @ 2014-12-02 8:48 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
This patch series contains two hardware setting modification to prevent
hardware become abnormal.
Chunhao Lin (2):
r8169:prevent enable hardware tx/rx too early
r8169:disable rtl8168ep cmac engine
drivers/net/ethernet/realtek/r8169.c | 33 ++++++++++++++++++++++-----------
1 file changed, 22 insertions(+), 11 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH net-next 1/2] r8169:prevent enable hardware tx/rx too early
From: Chunhao Lin @ 2014-12-02 8:48 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1417510111-3568-1-git-send-email-hau@realtek.com>
For RTL8168G/GU/H/EP and RTL8411B remove enable tx/rx from its own hw_start
function. This will prevent enable tx/rx before complete hardware tx/rx
setting.
Tx/Rx will be enabled in the end of function rtl_hw_start_8168.
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index cf154f7..7f4515f 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5934,7 +5934,6 @@ static void rtl_hw_start_8168g_1(struct rtl8169_private *tp)
rtl_w0w1_eri(tp, 0xdc, ERIAR_MASK_0001, 0x01, 0x00, ERIAR_EXGMAC);
rtl_eri_write(tp, 0x2f8, ERIAR_MASK_0011, 0x1d8f, ERIAR_EXGMAC);
- RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
RTL_W32(MISC, RTL_R32(MISC) & ~RXDV_GATED_EN);
RTL_W8(MaxTxPacketSize, EarlySize);
@@ -6027,7 +6026,6 @@ static void rtl_hw_start_8168h_1(struct rtl8169_private *tp)
rtl_eri_write(tp, 0x5f0, ERIAR_MASK_0011, 0x4f87, ERIAR_EXGMAC);
- RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
RTL_W32(MISC, RTL_R32(MISC) & ~RXDV_GATED_EN);
RTL_W8(MaxTxPacketSize, EarlySize);
@@ -6109,7 +6107,6 @@ static void rtl_hw_start_8168ep(struct rtl8169_private *tp)
rtl_eri_write(tp, 0x5f0, ERIAR_MASK_0011, 0x4f87, ERIAR_EXGMAC);
- RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
RTL_W32(MISC, RTL_R32(MISC) & ~RXDV_GATED_EN);
RTL_W8(MaxTxPacketSize, EarlySize);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 2/2] r8169:disable rtl8168ep cmac engine
From: Chunhao Lin @ 2014-12-02 8:48 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1417510111-3568-1-git-send-email-hau@realtek.com>
Cmac engine is the bridge between driver and dash firmware.
Other os may not disable cmac when leave. And r8169 did not allocate any
resources for cmac engine. Disable it to prevent abnormal system behavior.
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 30 ++++++++++++++++++++++--------
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 7f4515f..56280c1 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1377,6 +1377,16 @@ DECLARE_RTL_COND(rtl_ocp_tx_cond)
return RTL_R8(IBISR0) & 0x02;
}
+static void rtl8168ep_stop_cmac(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+
+ RTL_W8(IBCR2, RTL_R8(IBCR2) & ~0x01);
+ rtl_msleep_loop_wait_low(tp, &rtl_ocp_tx_cond, 50, 2000);
+ RTL_W8(IBISR0, RTL_R8(IBISR0) | 0x20);
+ RTL_W8(IBCR0, RTL_R8(IBCR0) & ~0x01);
+}
+
static void rtl8168dp_driver_start(struct rtl8169_private *tp)
{
rtl8168_oob_notify(tp, OOB_CMD_DRIVER_START);
@@ -1417,12 +1427,7 @@ static void rtl8168dp_driver_stop(struct rtl8169_private *tp)
static void rtl8168ep_driver_stop(struct rtl8169_private *tp)
{
- void __iomem *ioaddr = tp->mmio_addr;
-
- RTL_W8(IBCR2, RTL_R8(IBCR2) & ~0x01);
- rtl_msleep_loop_wait_low(tp, &rtl_ocp_tx_cond, 50, 2000);
- RTL_W8(IBISR0, RTL_R8(IBISR0) | 0x20);
- RTL_W8(IBCR0, RTL_R8(IBCR0) & ~0x01);
+ rtl8168ep_stop_cmac(tp);
ocp_write(tp, 0x01, 0x180, OOB_CMD_DRIVER_STOP);
ocp_write(tp, 0x01, 0x30, ocp_read(tp, 0x01, 0x30) | 0x01);
rtl_msleep_loop_wait_low(tp, &rtl_ep_ocp_read_cond, 10, 10);
@@ -6089,6 +6094,8 @@ static void rtl_hw_start_8168ep(struct rtl8169_private *tp)
void __iomem *ioaddr = tp->mmio_addr;
struct pci_dev *pdev = tp->pci_dev;
+ rtl8168ep_stop_cmac(tp);
+
RTL_W32(TxConfig, RTL_R32(TxConfig) | TXCFG_AUTO_FIFO);
rtl_eri_write(tp, 0xc8, ERIAR_MASK_0101, 0x00080002, ERIAR_EXGMAC);
@@ -8002,6 +8009,12 @@ static void rtl_hw_init_8168g(struct rtl8169_private *tp)
return;
}
+static void rtl_hw_init_8168ep(struct rtl8169_private *tp)
+{
+ rtl8168ep_stop_cmac(tp);
+ rtl_hw_init_8168g(tp);
+}
+
static void rtl_hw_initialize(struct rtl8169_private *tp)
{
switch (tp->mac_version) {
@@ -8014,12 +8027,13 @@ static void rtl_hw_initialize(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_46:
case RTL_GIGA_MAC_VER_47:
case RTL_GIGA_MAC_VER_48:
+ rtl_hw_init_8168g(tp);
+ break;
case RTL_GIGA_MAC_VER_49:
case RTL_GIGA_MAC_VER_50:
case RTL_GIGA_MAC_VER_51:
- rtl_hw_init_8168g(tp);
+ rtl_hw_init_8168ep(tp);
break;
-
default:
break;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
From: Michael S. Tsirkin @ 2014-12-02 9:43 UTC (permalink / raw)
To: Jason Wang; +Cc: pagupta, netdev, davem, linux-kernel, virtualization
In-Reply-To: <1417507622.12638.0@smtp.corp.redhat.com>
On Tue, Dec 02, 2014 at 08:15:02AM +0008, Jason Wang wrote:
>
>
> On Tue, Dec 2, 2014 at 11:15 AM, Jason Wang <jasowang@redhat.com> wrote:
> >
> >
> >On Mon, Dec 1, 2014 at 6:42 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >>On Mon, Dec 01, 2014 at 06:17:03PM +0800, Jason Wang wrote:
> >>> Hello:
> >>> We used to orphan packets before transmission for virtio-net. This
> >>>breaks
> >>> socket accounting and can lead serveral functions won't work, e.g:
> >>> - Byte Queue Limit depends on tx completion nofication to work.
> >>> - Packet Generator depends on tx completion nofication for the last
> >>> transmitted packet to complete.
> >>> - TCP Small Queue depends on proper accounting of sk_wmem_alloc to
> >>>work.
> >>> This series tries to solve the issue by enabling tx interrupts. To
> >>>minize
> >>> the performance impacts of this, several optimizations were used:
> >>> - In guest side, virtqueue_enable_cb_delayed() was used to delay the
> >>>tx
> >>> interrupt untile 3/4 pending packets were sent.
> >>> - In host side, interrupt coalescing were used to reduce tx
> >>>interrupts.
> >>> Performance test results[1] (tx-frames 16 tx-usecs 16) shows:
> >>> - For guest receiving. No obvious regression on throughput were
> >>> noticed. More cpu utilization were noticed in few cases.
> >>> - For guest transmission. Very huge improvement on througput for
> >>>small
> >>> packet transmission were noticed. This is expected since TSQ and
> >>>other
> >>> optimization for small packet transmission work after tx interrupt.
> >>>But
> >>> will use more cpu for large packets.
> >>> - For TCP_RR, regression (10% on transaction rate and cpu
> >>>utilization) were
> >>> found. Tx interrupt won't help but cause overhead in this case.
> >>>Using
> >>> more aggressive coalescing parameters may help to reduce the
> >>>regression.
> >>
> >>OK, you do have posted coalescing patches - does it help any?
> >
> >Helps a lot.
> >
> >For RX, it saves about 5% - 10% cpu. (reduce 60%-90% tx intrs)
> >For small packet TX, it increases 33% - 245% throughput. (reduce about 60%
> >inters)
> >For TCP_RR, it increase the 3%-10% trans.rate. (reduce 40%-80% tx intrs)
> >
> >>
> >>I'm not sure the regression is due to interrupts.
> >>It would make sense for CPU but why would it
> >>hurt transaction rate?
> >
> >Anyway guest need to take some cycles to handle tx interrupts.
> >And transaction rate does increase if we coalesces more tx interurpts.
> >>
> >>
> >>It's possible that we are deferring kicks too much due to BQL.
> >>
> >>As an experiment: do we get any of it back if we do
> >>- if (kick || netif_xmit_stopped(txq))
> >>- virtqueue_kick(sq->vq);
> >>+ virtqueue_kick(sq->vq);
> >>?
> >
> >
> >I will try, but during TCP_RR, at most 1 packets were pending,
> >I suspect if BQL can help in this case.
>
> Looks like this helps a lot in multiple sessions of TCP_RR.
so what's faster
BQL + kick each packet
no BQL
?
> How about move the BQL patch out of this series?
>
> Let's first converge tx interrupt and then introduce it?
> (e.g with kicking after queuing X bytes?)
Sounds good.
^ permalink raw reply
* Re: [PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
From: Jason Wang @ 2014-12-02 9:51 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: pagupta, netdev, davem, linux-kernel, virtualization
In-Reply-To: <20141202094318.GB7732@redhat.com>
On Tue, Dec 2, 2014 at 5:43 PM, Michael S. Tsirkin <mst@redhat.com>
wrote:
> On Tue, Dec 02, 2014 at 08:15:02AM +0008, Jason Wang wrote:
>>
>>
>> On Tue, Dec 2, 2014 at 11:15 AM, Jason Wang <jasowang@redhat.com>
>> wrote:
>> >
>> >
>> >On Mon, Dec 1, 2014 at 6:42 PM, Michael S. Tsirkin
>> <mst@redhat.com> wrote:
>> >>On Mon, Dec 01, 2014 at 06:17:03PM +0800, Jason Wang wrote:
>> >>> Hello:
>> >>> We used to orphan packets before transmission for virtio-net.
>> This
>> >>>breaks
>> >>> socket accounting and can lead serveral functions won't work,
>> e.g:
>> >>> - Byte Queue Limit depends on tx completion nofication to work.
>> >>> - Packet Generator depends on tx completion nofication for the
>> last
>> >>> transmitted packet to complete.
>> >>> - TCP Small Queue depends on proper accounting of sk_wmem_alloc
>> to
>> >>>work.
>> >>> This series tries to solve the issue by enabling tx
>> interrupts. To
>> >>>minize
>> >>> the performance impacts of this, several optimizations were
>> used:
>> >>> - In guest side, virtqueue_enable_cb_delayed() was used to
>> delay the
>> >>>tx
>> >>> interrupt untile 3/4 pending packets were sent.
>> >>> - In host side, interrupt coalescing were used to reduce tx
>> >>>interrupts.
>> >>> Performance test results[1] (tx-frames 16 tx-usecs 16) shows:
>> >>> - For guest receiving. No obvious regression on throughput were
>> >>> noticed. More cpu utilization were noticed in few cases.
>> >>> - For guest transmission. Very huge improvement on througput for
>> >>>small
>> >>> packet transmission were noticed. This is expected since TSQ
>> and
>> >>>other
>> >>> optimization for small packet transmission work after tx
>> interrupt.
>> >>>But
>> >>> will use more cpu for large packets.
>> >>> - For TCP_RR, regression (10% on transaction rate and cpu
>> >>>utilization) were
>> >>> found. Tx interrupt won't help but cause overhead in this
>> case.
>> >>>Using
>> >>> more aggressive coalescing parameters may help to reduce the
>> >>>regression.
>> >>
>> >>OK, you do have posted coalescing patches - does it help any?
>> >
>> >Helps a lot.
>> >
>> >For RX, it saves about 5% - 10% cpu. (reduce 60%-90% tx intrs)
>> >For small packet TX, it increases 33% - 245% throughput. (reduce
>> about 60%
>> >inters)
>> >For TCP_RR, it increase the 3%-10% trans.rate. (reduce 40%-80% tx
>> intrs)
>> >
>> >>
>> >>I'm not sure the regression is due to interrupts.
>> >>It would make sense for CPU but why would it
>> >>hurt transaction rate?
>> >
>> >Anyway guest need to take some cycles to handle tx interrupts.
>> >And transaction rate does increase if we coalesces more tx
>> interurpts.
>> >>
>> >>
>> >>It's possible that we are deferring kicks too much due to BQL.
>> >>
>> >>As an experiment: do we get any of it back if we do
>> >>- if (kick || netif_xmit_stopped(txq))
>> >>- virtqueue_kick(sq->vq);
>> >>+ virtqueue_kick(sq->vq);
>> >>?
>> >
>> >
>> >I will try, but during TCP_RR, at most 1 packets were pending,
>> >I suspect if BQL can help in this case.
>>
>> Looks like this helps a lot in multiple sessions of TCP_RR.
>
> so what's faster
> BQL + kick each packet
> no BQL
> ?
Quick and manual tests (TCP_RR 64, TCP_STREAM 512) does not
show obvious differences.
May need a complete benchmark to see.
>
>
>> How about move the BQL patch out of this series?
>>
>> Let's first converge tx interrupt and then introduce it?
>> (e.g with kicking after queuing X bytes?)
>
> Sounds good.
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-12-02 9:55 UTC (permalink / raw)
To: Kevin Zhu
Cc: Eli Britstein, Bjørn Mork, Alex Strizhevsky,
Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <547D6D7B.5090704-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 8675 bytes --]
Mhmhm; trying to change different values in the cdc_ncm.c driver might be the
only way.
I am sorry - I am not noticing strange things, but fixed parameters.
Try to change them ... I can not do that, I lost my test system due to a
kernel-related programming error, so for now I am a passive observer.
On Tue, 2 Dec 2014, Kevin Zhu wrote:
==Date: Tue, 2 Dec 2014 08:44:11
==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==Cc: Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>,
== Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
== Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
== "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
== "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
== "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==Subject: Re: Is this 32-bit NCM?
==
==Hi all,
==
==Here's the registry from windows 7. Attached. One parameter that might
==be interesting is MaxNumOfDatagramInNTB, which is 64. I wonder if it has
==something to do with MaxDatagramSize. Can someone also check the
==registry, in case I missed something?
==
==Regards,
==Kevin
==
==On 12/02/2014 02:49 PM, Enrico Mioso wrote:
==> Can you try to look at Windows registry keys based on the INF file as suggested
==> or would this be a problem for you?
==> And... if you have any Huawei manutal talking about it: even device's
==> ^DSFLOWRPT
==> might be useful to some extent, but ... this is only just a note in case we
==> don't find anything else.
==> Regards ... and good day to all of you,
==> Enrico
==>
==>
==> On Tue, 2 Dec 2014, Kevin Zhu wrote:
==>
==> ==Date: Tue, 2 Dec 2014 07:43:24
==> ==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==> ==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==> ==Cc: Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>,
==> == Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==> == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
==> == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==> == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
==> == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==> ==Subject: Re: Is this 32-bit NCM?
==> ==
==> ==I also tried to define CDC_NCM_DPT_DATAGRAMS_MAX as 1 to eliminate the
==> ==paddings, but it did not work either, not even DHCP.
==> ==
==> ==Regards,
==> ==Kevin
==> ==
==> ==On 12/02/2014 02:32 PM, Enrico Mioso wrote:
==> ==> Hi again Eli,
==> ==> Hi Kevin,
==> ==> Hi everyone...
==> ==>
==> ==> As I understand it anyway - the distinction here tends not to be between
==> ==> different types of packets.
==> ==> It tends to be between received and sent packet.
==> ==> We are not able to generate packets that the device retains valid.
==> ==> If you manually configure the IP the device would have assigned you via DHCP,
==> ==> your system will start answering ARP request, saying that the host with IP
==> ==> aa.bb.cc.dd is at aa:bb:cc:dd:ee (using the MC address of the dongle).
==> ==> However, the other host (gateway) will never know that. Indeed, it'll continue
==> ==> asking who-is at aa.bb.cc.dd ?
==> ==> At least, this is the situation I observed in the test system.
==> ==>
==> ==>
==> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote:
==> ==>
==> ==> ==Date: Tue, 2 Dec 2014 04:53:53
==> ==> ==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==> ==> ==To: Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
==> ==> == Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==> ==> ==Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==> ==> == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
==> ==> == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==> ==> == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
==> ==> == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==> ==> ==Subject: Re: Is this 32-bit NCM?
==> ==> ==
==> ==> ==Hi,
==> ==> ==
==> ==> ==The DHCP packets have the maximum size of dwNtbOutMaxSize=16384, while
==> ==> ==the other packets are less than that. However, the DHCP queries are not
==> ==> ==replied in time either, there's always some delay.
==> ==> ==
==> ==> ==By the way, though the device claims to support GET_MAX_DATAGRAM_SIZE,
==> ==> ==but it returns error when the host sends this command to it. I disabled
==> ==> ==this command in NCM driver and tried, but it's the same result.
==> ==> ==
==> ==> ==Regards,
==> ==> ==Kevin
==> ==> ==
==> ==> ==On 12/02/2014 06:02 AM, Eli Britstein wrote:
==> ==> ==> Hi Enrico and all,
==> ==> ==>
==> ==> ==> Maybe I missed something but what is the difference by the driver point of view between the dhcp discover and request (that are ok) to others (like arp, that is nok)?
==> ==> ==> Maybe we can trace to compare them?
==> ==> ==>
==> ==> ==> Sent from my iPhone
==> ==> ==>
==> ==> ==>> On 1 בדצמ 2014, at 23:11, "Enrico Mioso" <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
==> ==> ==>>
==> ==> ==>> So ... I have two ideas left for now.
==> ==> ==>> We know for sure the problem is in the way we TX frames, not the way we RX them
==> ==> ==>> (the way we send, generate them, not the way we receive them).
==> ==> ==>> Si I have two ideas, and I ask for help from the Linux-usb mailing list for
==> ==> ==>> this first one.
==> ==> ==>>
==> ==> ==>> 1 - Does a wayexist to "replay" traffic crom a usb capture?
==> ==> ==>> We might try to take the usb frames generated by Windows, and send them to the
==> ==> ==>> device to see if there is any reaction. It should not be science fiction, I saw
==> ==> ==>> them do that in the eciadsl old project.
==> ==> ==>> 2 - The huawei ndis driver: does it work with these devices?
==> ==> ==>> It should be a little bit out-dated now (at least in terms of dates, it might
==> ==> ==>> work as well): the code is A LOT but, just in case, to see if there is any
==> ==> ==>> chances it'll work. It remains to be seen in which kernels it can actually
==> ==> ==>> compile again.
==> ==> ==>>
==> ==> ==>> If this works we might analyse what's happening and try to debug this out.
==> ==> ==>> But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm.
==> ==> ==>> Thank you.
==> ==> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
==> ==> ==
==> ==> ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
==> ==> ==
==> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
==> ==
==> ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
==> ==
==
==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
==
==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
==
^ permalink raw reply
* Re: [PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
From: Michael S. Tsirkin @ 2014-12-02 9:55 UTC (permalink / raw)
To: Jason Wang; +Cc: pagupta, netdev, davem, linux-kernel, virtualization
In-Reply-To: <1417513908.16540.0@smtp.corp.redhat.com>
On Tue, Dec 02, 2014 at 09:59:48AM +0008, Jason Wang wrote:
>
>
> On Tue, Dec 2, 2014 at 5:43 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >On Tue, Dec 02, 2014 at 08:15:02AM +0008, Jason Wang wrote:
> >> On Tue, Dec 2, 2014 at 11:15 AM, Jason Wang <jasowang@redhat.com>
> >>wrote:
> >> >
> >> >
> >> >On Mon, Dec 1, 2014 at 6:42 PM, Michael S. Tsirkin <mst@redhat.com>
> >>wrote:
> >> >>On Mon, Dec 01, 2014 at 06:17:03PM +0800, Jason Wang wrote:
> >> >>> Hello:
> >> >>> We used to orphan packets before transmission for virtio-net. This
> >> >>>breaks
> >> >>> socket accounting and can lead serveral functions won't work, e.g:
> >> >>> - Byte Queue Limit depends on tx completion nofication to work.
> >> >>> - Packet Generator depends on tx completion nofication for the last
> >> >>> transmitted packet to complete.
> >> >>> - TCP Small Queue depends on proper accounting of sk_wmem_alloc to
> >> >>>work.
> >> >>> This series tries to solve the issue by enabling tx interrupts. To
> >> >>>minize
> >> >>> the performance impacts of this, several optimizations were used:
> >> >>> - In guest side, virtqueue_enable_cb_delayed() was used to delay
> >>the
> >> >>>tx
> >> >>> interrupt untile 3/4 pending packets were sent.
> >> >>> - In host side, interrupt coalescing were used to reduce tx
> >> >>>interrupts.
> >> >>> Performance test results[1] (tx-frames 16 tx-usecs 16) shows:
> >> >>> - For guest receiving. No obvious regression on throughput were
> >> >>> noticed. More cpu utilization were noticed in few cases.
> >> >>> - For guest transmission. Very huge improvement on througput for
> >> >>>small
> >> >>> packet transmission were noticed. This is expected since TSQ and
> >> >>>other
> >> >>> optimization for small packet transmission work after tx
> >>interrupt.
> >> >>>But
> >> >>> will use more cpu for large packets.
> >> >>> - For TCP_RR, regression (10% on transaction rate and cpu
> >> >>>utilization) were
> >> >>> found. Tx interrupt won't help but cause overhead in this case.
> >> >>>Using
> >> >>> more aggressive coalescing parameters may help to reduce the
> >> >>>regression.
> >> >>
> >> >>OK, you do have posted coalescing patches - does it help any?
> >> >
> >> >Helps a lot.
> >> >
> >> >For RX, it saves about 5% - 10% cpu. (reduce 60%-90% tx intrs)
> >> >For small packet TX, it increases 33% - 245% throughput. (reduce about
> >>60%
> >> >inters)
> >> >For TCP_RR, it increase the 3%-10% trans.rate. (reduce 40%-80% tx
> >>intrs)
> >> >
> >> >>
> >> >>I'm not sure the regression is due to interrupts.
> >> >>It would make sense for CPU but why would it
> >> >>hurt transaction rate?
> >> >
> >> >Anyway guest need to take some cycles to handle tx interrupts.
> >> >And transaction rate does increase if we coalesces more tx interurpts.
> >> >>
> >> >>
> >> >>It's possible that we are deferring kicks too much due to BQL.
> >> >>
> >> >>As an experiment: do we get any of it back if we do
> >> >>- if (kick || netif_xmit_stopped(txq))
> >> >>- virtqueue_kick(sq->vq);
> >> >>+ virtqueue_kick(sq->vq);
> >> >>?
> >> >
> >> >
> >> >I will try, but during TCP_RR, at most 1 packets were pending,
> >> >I suspect if BQL can help in this case.
> >> Looks like this helps a lot in multiple sessions of TCP_RR.
> >
> >so what's faster
> > BQL + kick each packet
> > no BQL
> >?
>
> Quick and manual tests (TCP_RR 64, TCP_STREAM 512) does not show obvious
> differences.
>
> May need a complete benchmark to see.
Okay so going forward something like BQL + kick each packet
might be a good solution.
The advantage of BQL is that it works without GSO.
For example, now that we don't do UFO, you might
see significant gains with UDP.
> >
> >
> >> How about move the BQL patch out of this series?
> >> Let's first converge tx interrupt and then introduce it?
> >> (e.g with kicking after queuing X bytes?)
> >
> >Sounds good.
^ permalink raw reply
* RE: [PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
From: David Laight @ 2014-12-02 10:00 UTC (permalink / raw)
To: 'Jason Wang', Michael S. Tsirkin
Cc: pagupta@redhat.com, netdev@vger.kernel.org, davem@davemloft.net,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
In-Reply-To: <1417490120.4405.2@smtp.corp.redhat.com>
From: Jason Wang
> > On Mon, Dec 01, 2014 at 06:17:03PM +0800, Jason Wang wrote:
> >> Hello:
> >>
> >> We used to orphan packets before transmission for virtio-net. This
> >> breaks
> >> socket accounting and can lead serveral functions won't work, e.g:
> >>
> >> - Byte Queue Limit depends on tx completion nofication to work.
> >> - Packet Generator depends on tx completion nofication for the last
> >> transmitted packet to complete.
> >> - TCP Small Queue depends on proper accounting of sk_wmem_alloc to
> >> work.
> >>
> >> This series tries to solve the issue by enabling tx interrupts. To
> >> minize
> >> the performance impacts of this, several optimizations were used:
> >>
> >> - In guest side, virtqueue_enable_cb_delayed() was used to delay the tx
> >> interrupt untile 3/4 pending packets were sent.
Doesn't that give problems for intermittent transmits?
...
David
^ permalink raw reply
* Re: [PATCH net-next] rtnetlink: delay RTM_DELLINK notification until after ndo_uninit()
From: Thomas Graf @ 2014-12-02 10:07 UTC (permalink / raw)
To: Mahesh Bandewar
Cc: netdev, David Miller, Eric Dumazet, Roopa Prabhu, Toshiaki Makita
In-Reply-To: <1417499650-29176-1-git-send-email-maheshb@google.com>
On 12/01/14 at 09:54pm, Mahesh Bandewar wrote:
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -2220,8 +2220,16 @@ static int rtnl_dump_all(struct sk_buff *skb, struct netlink_callback *cb)
> return skb->len;
> }
>
> -void rtmsg_ifinfo(int type, struct net_device *dev, unsigned int change,
> - gfp_t flags)
> +void rtmsg_ifinfo_send(struct sk_buff *skb, struct net_device *dev, gfp_t flags)
> +{
> + struct net *net = dev_net(dev);
> +
> + rtnl_notify(skb, net, 0, RTNLGRP_LINK, NULL, flags);
> +}
> +EXPORT_SYMBOL(rtmsg_ifinfo_send);
> +
> +struct sk_buff *rtmsg_ifinfo(int type, struct net_device *dev,
> + unsigned int change, gfp_t flags, bool fill_only)
> {
> struct net *net = dev_net(dev);
> struct sk_buff *skb;
> @@ -2239,11 +2247,15 @@ void rtmsg_ifinfo(int type, struct net_device *dev, unsigned int change,
> kfree_skb(skb);
> goto errout;
> }
> + if (fill_only)
> + return skb;
> +
> rtnl_notify(skb, net, 0, RTNLGRP_LINK, NULL, flags);
> - return;
> + return NULL;
> errout:
> if (err < 0)
> rtnl_set_sk_err(net, RTNLGRP_LINK, err);
> + return NULL;
> }
I think it would be cleaner to introduce a new function, for example
rtmsg_ifinfo_build_skb() which is called from rtmsg_ifinfo(). The
single caller that requires delayed sending can use the build skb
function directly and then send it off.
^ permalink raw reply
* Re: [PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
From: Michael S. Tsirkin @ 2014-12-02 10:08 UTC (permalink / raw)
To: David Laight
Cc: pagupta@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, davem@davemloft.net
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CA007CC@AcuExch.aculab.com>
On Tue, Dec 02, 2014 at 10:00:06AM +0000, David Laight wrote:
> From: Jason Wang
> > > On Mon, Dec 01, 2014 at 06:17:03PM +0800, Jason Wang wrote:
> > >> Hello:
> > >>
> > >> We used to orphan packets before transmission for virtio-net. This
> > >> breaks
> > >> socket accounting and can lead serveral functions won't work, e.g:
> > >>
> > >> - Byte Queue Limit depends on tx completion nofication to work.
> > >> - Packet Generator depends on tx completion nofication for the last
> > >> transmitted packet to complete.
> > >> - TCP Small Queue depends on proper accounting of sk_wmem_alloc to
> > >> work.
> > >>
> > >> This series tries to solve the issue by enabling tx interrupts. To
> > >> minize
> > >> the performance impacts of this, several optimizations were used:
> > >>
> > >> - In guest side, virtqueue_enable_cb_delayed() was used to delay the tx
> > >> interrupt untile 3/4 pending packets were sent.
>
> Doesn't that give problems for intermittent transmits?
>
> ...
>
> David
>
No because it has not effect in that case.
--
MST
^ permalink raw reply
* Re: [PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
From: Pankaj Gupta @ 2014-12-02 10:08 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang
Cc: virtualization, netdev, linux-kernel, davem
In-Reply-To: <20141202095523.GA7877@redhat.com>
>
> On Tue, Dec 02, 2014 at 09:59:48AM +0008, Jason Wang wrote:
> >
> >
> > On Tue, Dec 2, 2014 at 5:43 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > >On Tue, Dec 02, 2014 at 08:15:02AM +0008, Jason Wang wrote:
> > >> On Tue, Dec 2, 2014 at 11:15 AM, Jason Wang <jasowang@redhat.com>
> > >>wrote:
> > >> >
> > >> >
> > >> >On Mon, Dec 1, 2014 at 6:42 PM, Michael S. Tsirkin <mst@redhat.com>
> > >>wrote:
> > >> >>On Mon, Dec 01, 2014 at 06:17:03PM +0800, Jason Wang wrote:
> > >> >>> Hello:
> > >> >>> We used to orphan packets before transmission for virtio-net. This
> > >> >>>breaks
> > >> >>> socket accounting and can lead serveral functions won't work, e.g:
> > >> >>> - Byte Queue Limit depends on tx completion nofication to work.
> > >> >>> - Packet Generator depends on tx completion nofication for the last
> > >> >>> transmitted packet to complete.
> > >> >>> - TCP Small Queue depends on proper accounting of sk_wmem_alloc to
> > >> >>>work.
> > >> >>> This series tries to solve the issue by enabling tx interrupts. To
> > >> >>>minize
> > >> >>> the performance impacts of this, several optimizations were used:
> > >> >>> - In guest side, virtqueue_enable_cb_delayed() was used to delay
> > >>the
> > >> >>>tx
> > >> >>> interrupt untile 3/4 pending packets were sent.
> > >> >>> - In host side, interrupt coalescing were used to reduce tx
> > >> >>>interrupts.
> > >> >>> Performance test results[1] (tx-frames 16 tx-usecs 16) shows:
> > >> >>> - For guest receiving. No obvious regression on throughput were
> > >> >>> noticed. More cpu utilization were noticed in few cases.
> > >> >>> - For guest transmission. Very huge improvement on througput for
> > >> >>>small
> > >> >>> packet transmission were noticed. This is expected since TSQ and
> > >> >>>other
> > >> >>> optimization for small packet transmission work after tx
> > >>interrupt.
> > >> >>>But
> > >> >>> will use more cpu for large packets.
> > >> >>> - For TCP_RR, regression (10% on transaction rate and cpu
> > >> >>>utilization) were
> > >> >>> found. Tx interrupt won't help but cause overhead in this case.
> > >> >>>Using
> > >> >>> more aggressive coalescing parameters may help to reduce the
> > >> >>>regression.
> > >> >>
> > >> >>OK, you do have posted coalescing patches - does it help any?
> > >> >
> > >> >Helps a lot.
> > >> >
> > >> >For RX, it saves about 5% - 10% cpu. (reduce 60%-90% tx intrs)
> > >> >For small packet TX, it increases 33% - 245% throughput. (reduce about
> > >>60%
> > >> >inters)
> > >> >For TCP_RR, it increase the 3%-10% trans.rate. (reduce 40%-80% tx
> > >>intrs)
> > >> >
> > >> >>
> > >> >>I'm not sure the regression is due to interrupts.
> > >> >>It would make sense for CPU but why would it
> > >> >>hurt transaction rate?
> > >> >
> > >> >Anyway guest need to take some cycles to handle tx interrupts.
> > >> >And transaction rate does increase if we coalesces more tx interurpts.
> > >> >>
> > >> >>
> > >> >>It's possible that we are deferring kicks too much due to BQL.
> > >> >>
> > >> >>As an experiment: do we get any of it back if we do
> > >> >>- if (kick || netif_xmit_stopped(txq))
> > >> >>- virtqueue_kick(sq->vq);
> > >> >>+ virtqueue_kick(sq->vq);
> > >> >>?
> > >> >
> > >> >
> > >> >I will try, but during TCP_RR, at most 1 packets were pending,
> > >> >I suspect if BQL can help in this case.
> > >> Looks like this helps a lot in multiple sessions of TCP_RR.
> > >
> > >so what's faster
> > > BQL + kick each packet
> > > no BQL
> > >?
> >
> > Quick and manual tests (TCP_RR 64, TCP_STREAM 512) does not show obvious
> > differences.
> >
> > May need a complete benchmark to see.
>
> Okay so going forward something like BQL + kick each packet
> might be a good solution.
> The advantage of BQL is that it works without GSO.
> For example, now that we don't do UFO, you might
> see significant gains with UDP.
If I understand correctly, it can also help for small packet
regr. in multiqueue scenario? Would be nice to see the perf. numbers
with multi-queue for small packets streams.
>
>
> > >
> > >
> > >> How about move the BQL patch out of this series?
> > >> Let's first converge tx interrupt and then introduce it?
> > >> (e.g with kicking after queuing X bytes?)
> > >
> > >Sounds good.
> --
> 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
>
^ permalink raw reply
* Re: [PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
From: Michael S. Tsirkin @ 2014-12-02 10:11 UTC (permalink / raw)
To: Pankaj Gupta; +Cc: netdev, davem, linux-kernel, virtualization
In-Reply-To: <251897174.7356500.1417514915101.JavaMail.zimbra@redhat.com>
On Tue, Dec 02, 2014 at 05:08:35AM -0500, Pankaj Gupta wrote:
>
> >
> > On Tue, Dec 02, 2014 at 09:59:48AM +0008, Jason Wang wrote:
> > >
> > >
> > > On Tue, Dec 2, 2014 at 5:43 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > > >On Tue, Dec 02, 2014 at 08:15:02AM +0008, Jason Wang wrote:
> > > >> On Tue, Dec 2, 2014 at 11:15 AM, Jason Wang <jasowang@redhat.com>
> > > >>wrote:
> > > >> >
> > > >> >
> > > >> >On Mon, Dec 1, 2014 at 6:42 PM, Michael S. Tsirkin <mst@redhat.com>
> > > >>wrote:
> > > >> >>On Mon, Dec 01, 2014 at 06:17:03PM +0800, Jason Wang wrote:
> > > >> >>> Hello:
> > > >> >>> We used to orphan packets before transmission for virtio-net. This
> > > >> >>>breaks
> > > >> >>> socket accounting and can lead serveral functions won't work, e.g:
> > > >> >>> - Byte Queue Limit depends on tx completion nofication to work.
> > > >> >>> - Packet Generator depends on tx completion nofication for the last
> > > >> >>> transmitted packet to complete.
> > > >> >>> - TCP Small Queue depends on proper accounting of sk_wmem_alloc to
> > > >> >>>work.
> > > >> >>> This series tries to solve the issue by enabling tx interrupts. To
> > > >> >>>minize
> > > >> >>> the performance impacts of this, several optimizations were used:
> > > >> >>> - In guest side, virtqueue_enable_cb_delayed() was used to delay
> > > >>the
> > > >> >>>tx
> > > >> >>> interrupt untile 3/4 pending packets were sent.
> > > >> >>> - In host side, interrupt coalescing were used to reduce tx
> > > >> >>>interrupts.
> > > >> >>> Performance test results[1] (tx-frames 16 tx-usecs 16) shows:
> > > >> >>> - For guest receiving. No obvious regression on throughput were
> > > >> >>> noticed. More cpu utilization were noticed in few cases.
> > > >> >>> - For guest transmission. Very huge improvement on througput for
> > > >> >>>small
> > > >> >>> packet transmission were noticed. This is expected since TSQ and
> > > >> >>>other
> > > >> >>> optimization for small packet transmission work after tx
> > > >>interrupt.
> > > >> >>>But
> > > >> >>> will use more cpu for large packets.
> > > >> >>> - For TCP_RR, regression (10% on transaction rate and cpu
> > > >> >>>utilization) were
> > > >> >>> found. Tx interrupt won't help but cause overhead in this case.
> > > >> >>>Using
> > > >> >>> more aggressive coalescing parameters may help to reduce the
> > > >> >>>regression.
> > > >> >>
> > > >> >>OK, you do have posted coalescing patches - does it help any?
> > > >> >
> > > >> >Helps a lot.
> > > >> >
> > > >> >For RX, it saves about 5% - 10% cpu. (reduce 60%-90% tx intrs)
> > > >> >For small packet TX, it increases 33% - 245% throughput. (reduce about
> > > >>60%
> > > >> >inters)
> > > >> >For TCP_RR, it increase the 3%-10% trans.rate. (reduce 40%-80% tx
> > > >>intrs)
> > > >> >
> > > >> >>
> > > >> >>I'm not sure the regression is due to interrupts.
> > > >> >>It would make sense for CPU but why would it
> > > >> >>hurt transaction rate?
> > > >> >
> > > >> >Anyway guest need to take some cycles to handle tx interrupts.
> > > >> >And transaction rate does increase if we coalesces more tx interurpts.
> > > >> >>
> > > >> >>
> > > >> >>It's possible that we are deferring kicks too much due to BQL.
> > > >> >>
> > > >> >>As an experiment: do we get any of it back if we do
> > > >> >>- if (kick || netif_xmit_stopped(txq))
> > > >> >>- virtqueue_kick(sq->vq);
> > > >> >>+ virtqueue_kick(sq->vq);
> > > >> >>?
> > > >> >
> > > >> >
> > > >> >I will try, but during TCP_RR, at most 1 packets were pending,
> > > >> >I suspect if BQL can help in this case.
> > > >> Looks like this helps a lot in multiple sessions of TCP_RR.
> > > >
> > > >so what's faster
> > > > BQL + kick each packet
> > > > no BQL
> > > >?
> > >
> > > Quick and manual tests (TCP_RR 64, TCP_STREAM 512) does not show obvious
> > > differences.
> > >
> > > May need a complete benchmark to see.
> >
> > Okay so going forward something like BQL + kick each packet
> > might be a good solution.
> > The advantage of BQL is that it works without GSO.
> > For example, now that we don't do UFO, you might
> > see significant gains with UDP.
>
> If I understand correctly, it can also help for small packet
> regr. in multiqueue scenario?
Well BQL generally should only be active for 1:1 mappings.
> Would be nice to see the perf. numbers
> with multi-queue for small packets streams.
> >
> >
> > > >
> > > >
> > > >> How about move the BQL patch out of this series?
> > > >> Let's first converge tx interrupt and then introduce it?
> > > >> (e.g with kicking after queuing X bytes?)
> > > >
> > > >Sounds good.
> > --
> > 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
> >
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-12-02 10:13 UTC (permalink / raw)
To: Kevin Zhu
Cc: Eli Britstein, Bjørn Mork, Alex Strizhevsky,
Midge Shaojun Tan, youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <547D7243.80508@audiocodes.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 17950 bytes --]
Ok - I am a newbie; but looking back at the mistake I did last time - I did
modify the memset call at line 1049 to change the padding.
This is wrong ... but, it was an attempt.
On Tue, 2 Dec 2014, Kevin Zhu wrote:
==Date: Tue, 2 Dec 2014 09:03:21
==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
==To: Eli Britstein <Eli.Britstein@audiocodes.com>,
== Enrico Mioso <mrkiko.rs@gmail.com>
==Cc: Bjørn Mork <bjorn@mork.no>, Alex Strizhevsky <alexxst@gmail.com>,
== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
== "youtux@gmail.com" <youtux@gmail.com>,
== "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
== "netdev@vger.kernel.org" <netdev@vger.kernel.org>
==Subject: Re: Is this 32-bit NCM?
==
==Below is the content of the INF file oem54.inf.
==
==; Copyright (c) 2010,2011 Huawei Incorporated
==; Manufacturer: Huawei Incorporated
==;
==; CDC ECM & NCM driver
==;
==
==[Version]
==Signature="$WINDOWS NT$"
==Class=Net
==ClassGUID={4d36e972-e325-11ce-bfc1-08002be10318}
==Provider=%Mfg%
==DriverVer=04/14/2014,1.0.13.0
==CatalogFile=ew_wwanecm.cat
==
==[Manufacturer]
==%Mfg% = DeviceList,NTx86,NTamd64
==
==[SourceDisksNames]
==1 = %ew_wwanecm.DiskName%,,,""
==
==[SourceDisksFiles]
==ew_wwanecm.sys = 1,,
==
==; For Win2K
==[DeviceList]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For WinXP and later
==[DeviceList.NTx86]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For XP and later x64
==[DeviceList.NTamd64]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==;-------------------------------------------------------------------------------
==
==; Virtual Ethernet Adapter
==;
==[ew_wwanecm.ndi]
==*IfType = 243 ; IF_TYPE_WWANPP
==*MediaType = 9; NdisMediumWirelessWan
==*PhysicalMediaType = 8 ; NdisPhysicalMediumWirelessWan
==EnableDhcp = 0 ; DHCP Disabled
==Characteristics = 0x84 ; NCF_HAS_UI | NCF_PHYSICAL
==BusType = 15 ; if you specify NCF_PHYSICAL, you must specify
==bustype
==AddReg = ew_wwanecm.Reg, ParamsPromiscuous, ParamsFrameType,
==ParamsIsNtb32, ParamsNTBInputSize, ParamsPacketsAccumulationTimeout,
==ParamsMaxNumOfDatagramsInNTB, FlowControlTimeOut,
==DisableAccumulationUpdate, WwanMbimEnable, NcmReinitializeEnable
==CopyFiles = ew_wwanecm.CopyFiles
==
==
==[WWAN_AddReg]
==HKR,, Platform,0x00010001,0x3
==HKR,, WWAN,0x00010001,0x1
==HKR,, "SelectiveSuspendIdleTime", 0x00010001, 0x05
==[ew_wwanecm.ndi.Services]
==AddService = %ServiceName%, 2, ew_wwanecm.Service, ew_wwanecm.EventLog
==
==[ew_wwanecm.ndi.HW]
==AddReg = WWAN_AddReg
==
==;-----------------------------------------------------------------------------
==
==;
==[ew_wwanecm.Reg]
==HKR, , BusNumber, 0, "0"
==HKR, , MPRadioState, 0x00010001,
==0x00000001 ;RadioState
==HKR, Ndi, Service, 0, "hwusb_wwanecm"
==HKR, Ndi\Interfaces, UpperRange, 0, "flpp4" and
=="flpp6"
==HKR, Ndi\Interfaces, LowerRange, 0, "ppip"
==
==[ParamsPromiscuous]
==;
==; Should the physical NIC be set to Promiscuous mode
==;
==HKR, Ndi\Params\Promiscuous, ParamDesc, , %Promiscuous%
==HKR, Ndi\Params\Promiscuous, Default, ,"0"
==HKR, Ndi\Params\Promiscuous, type, , enum
==HKR, Ndi\Params\Promiscuous\enum,"1", , %Promiscuous_Enable%
==HKR, Ndi\Params\Promiscuous\enum,"0", , %Promiscuous_Disable%
==
==[ParamsFrameType]
==HKR, Ndi\Params\FrameType, ParamDesc, 0, %FrameType%
==HKR, Ndi\Params\FrameType, type, 0, enum
==HKR, Ndi\Params\FrameType, Default, 0, "0"
==HKR, Ndi\Params\FrameType\enum,"1", 0, %FrameType_IP%
==HKR, Ndi\Params\FrameType\enum,"0", 0, %FrameType_Ethernet%
==
==[ParamsIsNtb32]
==HKR, Ndi\Params\IsNtb32, ParamDesc, , %IsNtb32%
==HKR, Ndi\Params\IsNtb32, Default, , "1"
==HKR, Ndi\Params\IsNtb32, type, , enum
==HKR, Ndi\Params\IsNtb32\enum, "1", , "Yes"
==HKR, Ndi\Params\IsNtb32\enum, "0", , "No"
==
==[ParamsNTBInputSize]
==HKR, Ndi\Params\NTBInputSize, ParamDesc, , %NTBInputSize%
==; If the following size is larger than the maximum allowed by the
==device, the
==; maximum value is used. 0 means to use the maximum allowed value of the
==device.
==HKR, Ndi\Params\NTBInputSize, Default, , "0"
==HKR, Ndi\Params\NTBInputSize, type, , dword
==
==[ParamsPacketsAccumulationTimeout]
==HKR, Ndi\Params\PacketsAccumulationTimeout, ParamDesc, ,
==%PacketsAccumulationTimeout%
==; Unit of PacketsAccumulationTimeout is usecs. Default value is 20 us.
==HKR, Ndi\Params\PacketsAccumulationTimeout, Default, , "20"
==HKR, Ndi\Params\PacketsAccumulationTimeout, type, , dword
==
==[ParamsMaxNumOfDatagramsInNTB]
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, ParamDesc, ,
==%MaxNumOfDatagramsInNTB%
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, Default, , "64"
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, type, , dword
==
==[FlowControlTimeOut]
==HKR, Ndi\Params\FlowControlTimeOut, ParamDesc, , %FlowControlTimeout%
==HKR, Ndi\Params\FlowControlTimeOut, Default, , "2800"
==HKR, Ndi\Params\FlowControlTimeOut, type, , dword
==
==[DisableAccumulationUpdate]
==HKR, Ndi\Params\disable_accumulation_update, ParamDesc, ,
==%DisableAccumulationUpdate%
==HKR, Ndi\Params\disable_accumulation_update, Default, , "0"
==HKR, Ndi\Params\disable_accumulation_update, type, , dword
==
==[WwanMbimEnable]
==HKR, Ndi\Params\WwanMbimEnable, ParamDesc, , %WwanMbimEnable%
==HKR, Ndi\Params\WwanMbimEnable, Default, , "0"
==HKR, Ndi\Params\WwanMbimEnable, type, , dword
==
==[NcmReinitializeEnable]
==HKR, Ndi\Params\NcmReinitializeEnable, ParamDesc, , %NcmReinitializeEnable%
==HKR, Ndi\Params\NcmReinitializeEnable, Default, , "1"
==HKR, Ndi\Params\NcmReinitializeEnable, type, , dword
==
==;-----------------------------------------------------------------------------
==
==; DestinationDirs
==;
==[DestinationDirs]
==ew_wwanecm.CopyFiles = 12
==
==[ew_wwanecm.CopyFiles]
==ew_wwanecm.sys,,,0x6 ;COPYFLG_NOSKIP | COPYFLG_NOVERSIONCHECK
==;-----------------------------------------------------------------------------
==
==; Driver and Service Section
==;
==
==[ew_wwanecm.Service]
==ServiceType = 1 ;%SERVICE_KERNEL_DRIVER%
==StartType = 3 ;%SERVICE_DEMAND_START%
==ErrorControl = 1 ;%SERVICE_ERROR_NORMAL%
==ServiceBinary = %12%\ew_wwanecm.sys
==LoadOrderGroup = NDIS
==AddReg = ew_wwanecm.Service.Reg
==
==[ew_wwanecm.Service.Reg]
==HKR, , TextModeFlags, 0x00010001, 0x0001
==HKR, Parameters, DebugLevel, 0x00010001, 1
==HKR, Parameters, WwanLogoTestOn, 0x00010001, 0
==
==[ew_wwanecm.EventLog]
==AddReg = ew_wwanecm.AddEventLog.Reg
==
==[ew_wwanecm.AddEventLog.Reg]
==HKR, , EventMessageFile, 0x00020000, "%%SystemRoot%%\System32\netevent.dll"
==HKR, , TypesSupported, 0x00010001, 7
==
==;-----------------------------------------------------------------------------
==
==; Localizable Strings
==;
==[Strings]
==Mfg = "HUAWEI"
==
==HUAWEI_NDISDeviceDesc = "HUAWEI Mobile Connect - Network Adapter"
==
==;PNP2.1 Device descriptor
==PNP21_HW_3G_NetworkDesc = "HUAWEI Mobile Connect - 3G Network Card"
==PNP21_HW_NetworkDesc = "HUAWEI Mobile Connect - Network Card"
==PNP21_NetworkDesc = "Mobile Connect - Network Card"
==PNP21_VDF_NetworkDesc = "Vodafone Mobile Broadband Network Adapter
==(Huawei)"
==
==ew_wwanecm.DiskName = "DriverCore Installation Disk"
==Promiscuous = "Set the physical NIC to promiscuous mode"
==Promiscuous_Disable = "Disable"
==ServiceName = "hwusb_wwanecm"
==Promiscuous_Enable = "Enable"
==FrameType = "Frame Type in driver-device communications"
==FrameType_Ethernet = "Ethernet"
==FrameType_IP = "IP"
==
==IsNtb32 = "32bit mode"
==NTBInputSize = "NTB input size"
==PacketsAccumulationTimeout = "Packets Accumulation Timeout [usec]"
==MaxNumOfDatagramsInNTB = "Maximum number of datagrams in NTB"
==FlowControlTimeout = "Flow Control timeout interval in ms"
==DisableAccumulationUpdate = "Flag to disable NCM accumulation auto
==updation"
==WwanMbimEnable = "Flag to enable WWAN MBIM function"
==NcmReinitializeEnable = "Flag to enable NCM reinitialize after resume"
==
==Regards,
==Kevin
==
==On 12/02/2014 03:45 PM, Eli Britstein wrote:
==> Outlook blocked the attachment. Please zip it and resend.
==>
==> Thanks,
==> Best regards,
==>
==> Eli Britstein
==> SW Team Leader and Project Manager
==> MP2xx Residential Gateways
==>
==> Tel: +972-3-9764148
==> Mobile: +972-54-2312677
==> Fax: +972-3-9764040
==> Email: Eli.Britstein@audiocodes.com
==> Web: www.audiocodes.com
==>
==>
==>
==> -----Original Message-----
==> From: Kevin Zhu
==> Sent: Tuesday, December 02, 2014 9:44
==> To: Enrico Mioso
==> Cc: Eli Britstein; Bjørn Mork; Alex Strizhevsky; Midge Shaojun Tan; youtux@gmail.com; linux-usb@vger.kernel.org; netdev@vger.kernel.org
==> Subject: Re: Is this 32-bit NCM?
==>
==> Hi all,
==>
==> Here's the registry from windows 7. Attached. One parameter that might be interesting is MaxNumOfDatagramInNTB, which is 64. I wonder if it has something to do with MaxDatagramSize. Can someone also check the registry, in case I missed something?
==>
==> Regards,
==> Kevin
==>
==> On 12/02/2014 02:49 PM, Enrico Mioso wrote:
==>> Can you try to look at Windows registry keys based on the INF file as
==>> suggested or would this be a problem for you?
==>> And... if you have any Huawei manutal talking about it: even device's
==>> ^DSFLOWRPT might be useful to some extent, but ... this is only just a
==>> note in case we don't find anything else.
==>> Regards ... and good day to all of you, Enrico
==>>
==>>
==>> On Tue, 2 Dec 2014, Kevin Zhu wrote:
==>>
==>> ==Date: Tue, 2 Dec 2014 07:43:24
==>> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
==>> ==To: Enrico Mioso <mrkiko.rs@gmail.com>
==>> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, Bjørn Mork <bjorn@mork.no>,
==>> == Alex Strizhevsky <alexxst@gmail.com>,
==>> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
==>> == "youtux@gmail.com" <youtux@gmail.com>,
==>> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
==>> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
==>> ==Subject: Re: Is this 32-bit NCM?
==>> ==
==>> ==I also tried to define CDC_NCM_DPT_DATAGRAMS_MAX as 1 to eliminate
==>> the ==paddings, but it did not work either, not even DHCP.
==>> ==
==>> ==Regards,
==>> ==Kevin
==>> ==
==>> ==On 12/02/2014 02:32 PM, Enrico Mioso wrote:
==>> ==> Hi again Eli,
==>> ==> Hi Kevin,
==>> ==> Hi everyone...
==>> ==>
==>> ==> As I understand it anyway - the distinction here tends not to be
==>> between ==> different types of packets.
==>> ==> It tends to be between received and sent packet.
==>> ==> We are not able to generate packets that the device retains valid.
==>> ==> If you manually configure the IP the device would have assigned
==>> you via DHCP, ==> your system will start answering ARP request, saying
==>> that the host with IP ==> aa.bb.cc.dd is at aa:bb:cc:dd:ee (using the MC address of the dongle).
==>> ==> However, the other host (gateway) will never know that. Indeed,
==>> it'll continue ==> asking who-is at aa.bb.cc.dd ?
==>> ==> At least, this is the situation I observed in the test system.
==>> ==>
==>> ==>
==>> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote:
==>> ==>
==>> ==> ==Date: Tue, 2 Dec 2014 04:53:53
==>> ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> ==> ==To: Eli
==>> Britstein <Eli.Britstein@audiocodes.com>,
==>> ==> == Enrico Mioso <mrkiko.rs@gmail.com>
==>> ==> ==Cc: Bjørn Mork <bjorn@mork.no>, Alex Strizhevsky <alexxst@gmail.com>,
==>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
==>> ==> == "youtux@gmail.com" <youtux@gmail.com>,
==>> ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
==>> ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
==>> ==> ==Subject: Re: Is this 32-bit NCM?
==>> ==> ==
==>> ==> ==Hi,
==>> ==> ==
==>> ==> ==The DHCP packets have the maximum size of dwNtbOutMaxSize=16384,
==>> while ==> ==the other packets are less than that. However, the DHCP
==>> queries are not ==> ==replied in time either, there's always some delay.
==>> ==> ==
==>> ==> ==By the way, though the device claims to support
==>> GET_MAX_DATAGRAM_SIZE, ==> ==but it returns error when the host sends
==>> this command to it. I disabled ==> ==this command in NCM driver and tried, but it's the same result.
==>> ==> ==
==>> ==> ==Regards,
==>> ==> ==Kevin
==>> ==> ==
==>> ==> ==On 12/02/2014 06:02 AM, Eli Britstein wrote:
==>> ==> ==> Hi Enrico and all,
==>> ==> ==>
==>> ==> ==> Maybe I missed something but what is the difference by the driver point of view between the dhcp discover and request (that are ok) to others (like arp, that is nok)?
==>> ==> ==> Maybe we can trace to compare them?
==>> ==> ==>
==>> ==> ==> Sent from my iPhone
==>> ==> ==>
==>> ==> ==>> On 1 בדצמ 2014, at 23:11, "Enrico Mioso" <mrkiko.rs@gmail.com> wrote:
==>> ==> ==>>
==>> ==> ==>> So ... I have two ideas left for now.
==>> ==> ==>> We know for sure the problem is in the way we TX frames, not
==>> the way we RX them ==> ==>> (the way we send, generate them, not the way we receive them).
==>> ==> ==>> Si I have two ideas, and I ask for help from the Linux-usb
==>> mailing list for ==> ==>> this first one.
==>> ==> ==>>
==>> ==> ==>> 1 - Does a wayexist to "replay" traffic crom a usb capture?
==>> ==> ==>> We might try to take the usb frames generated by Windows, and
==>> send them to the ==> ==>> device to see if there is any reaction. It
==>> should not be science fiction, I saw ==> ==>> them do that in the eciadsl old project.
==>> ==> ==>> 2 - The huawei ndis driver: does it work with these devices?
==>> ==> ==>> It should be a little bit out-dated now (at least in terms of
==>> dates, it might ==> ==>> work as well): the code is A LOT but, just in
==>> case, to see if there is any ==> ==>> chances it'll work. It remains
==>> to be seen in which kernels it can actually ==> ==>> compile again.
==>> ==> ==>>
==>> ==> ==>> If this works we might analyse what's happening and try to debug this out.
==>> ==> ==>> But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm.
==>> ==> ==>> Thank you.
==>> ==> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
==>> ==> ==
==>> ==> ==If you have received this email in error please immediately
==>> notify the sender and delete or destroy any copy of this message ==>
==>> == ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
==>> ==
==>> ==If you have received this email in error please immediately notify
==>> the sender and delete or destroy any copy of this message ==
==>
==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
==
==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
==
^ permalink raw reply
* Re: [RFC PATCH] netfilter: conntrack: cache route for forwarded connections
From: Florian Westphal @ 2014-12-02 10:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Florian Westphal, netfilter-devel, brouer, netdev
In-Reply-To: <1417484203.4442.19.camel@edumazet-glaptop2.roam.corp.google.com>
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2014-12-02 at 01:28 +0100, Florian Westphal wrote:
> > ... to avoid per-packet FIB lookup if possible.
> >
> > The cached dst is re-used provided the input interface
> > is the same as that of the previous packet in the same direction.
> >
> > If not, the cached dst is invalidated.
> >
> > This should speed up forwarding when conntrack is already in use
> > anyway, especially when using reverse path filtering -- active RPF
> > enforces two FIB lookups for each packet.
> >
> > Before the routing cache removal this didn't matter since RPF
> > was performed only when route cache didn't yield a result; but without
> > route cache it comes at high price.
> >
> > Signed-off-by: Florian Westphal <fw@strlen.de>
> > ---
>
> Seems a good idea (but you might need some IPv6 care, as ( dst =
> dst_check(dst, 0); ) seems to handle IPv4 only)
As usual, you're right...
AFAICS its enough to stash fib sernum of the rt6info too and pass
that as the cookie, phew :-)
> Another idea would be to re-use TCP ehash so that regular IP early demux
> can be used, with a single lookup for both local and forwarded sessions.
Hmm, I'll look at this. Maybe...
> (That would probably require a bit more memory, as you would need to
> insert into TCP ehash some kind of 'tiny sockets' )
... such tiny socket could be stored/tied to the conntrack extension
area.
I think we need to be careful to not re-add the route cache (and the DoS
issues associated with it).
Thanks Eric!
^ permalink raw reply
* Re: [RFC PATCH] netfilter: conntrack: cache route for forwarded connections
From: Florian Westphal @ 2014-12-02 10:21 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Florian Westphal, netfilter-devel, brouer, netdev
In-Reply-To: <alpine.LFD.2.11.1412020827260.1593@ja.home.ssi.bg>
Julian Anastasov <ja@ssi.bg> wrote:
> > The cached dst is re-used provided the input interface
> > is the same as that of the previous packet in the same direction.
> >
> > If not, the cached dst is invalidated.
> >
> > This should speed up forwarding when conntrack is already in use
> > anyway, especially when using reverse path filtering -- active RPF
> > enforces two FIB lookups for each packet.
> >
> > Before the routing cache removal this didn't matter since RPF
> > was performed only when route cache didn't yield a result; but without
> > route cache it comes at high price.
> >
> > Signed-off-by: Florian Westphal <fw@strlen.de>
> > ---
> > Sending as RFC since I haven't tested this yet (aside from
> > single-forwarded-flow), so no performance data either.
> >
> > - doesn't work when iif changes (it invalidates cached dst), don't
> > think its a problem
>
> The idea is good. But code that caches dsts should
> also handle at least NETDEV_UNREGISTER (NETDEV_DOWN being
> another option) to release dsts. Holding dsts for frozen
> conns in EST state for long time is a problem.
Okay, point taken. Thanks Julian.
^ 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