* Re: Is this 32-bit NCM?
From: Kevin Zhu @ 2014-12-02 6:43 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.1412020729470.1351@gmail.com>
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
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-12-02 6:49 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: <547D5F84.6020608@audiocodes.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 5571 bytes --]
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
==
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Kevin Zhu @ 2014-12-02 6:52 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>
OK. I will look at the windows driver and registry. I don't have any
manual of it.
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
* [PATCH net-next 2/8] tipc: make name table allocated dynamically
From: Ying Xue @ 2014-12-02 7:00 UTC (permalink / raw)
To: davem; +Cc: jon.maloy, netdev, Paul.Gortmaker, tipc-discussion
In-Reply-To: <1417503630-31352-1-git-send-email-ying.xue@windriver.com>
Name table locking policy is going to be adjusted from read-write
lock protection to RCU lock protection in the future commits. But
its essential precondition is to convert the allocation way of name
table from static to dynamic mode.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
---
net/tipc/name_distr.c | 44 +++++++++---------------------------
net/tipc/name_table.c | 60 ++++++++++++++++++++++++-------------------------
net/tipc/name_table.h | 16 ++++++++++++-
3 files changed, 55 insertions(+), 65 deletions(-)
diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
index 628cd85..ed00929 100644
--- a/net/tipc/name_distr.c
+++ b/net/tipc/name_distr.c
@@ -38,34 +38,6 @@
#include "link.h"
#include "name_distr.h"
-/**
- * struct publ_list - list of publications made by this node
- * @list: circular list of publications
- */
-struct publ_list {
- struct list_head list;
-};
-
-static struct publ_list publ_zone = {
- .list = LIST_HEAD_INIT(publ_zone.list),
-};
-
-static struct publ_list publ_cluster = {
- .list = LIST_HEAD_INIT(publ_cluster.list),
-};
-
-static struct publ_list publ_node = {
- .list = LIST_HEAD_INIT(publ_node.list),
-};
-
-static struct publ_list *publ_lists[] = {
- NULL,
- &publ_zone, /* publ_lists[TIPC_ZONE_SCOPE] */
- &publ_cluster, /* publ_lists[TIPC_CLUSTER_SCOPE] */
- &publ_node /* publ_lists[TIPC_NODE_SCOPE] */
-};
-
-
int sysctl_tipc_named_timeout __read_mostly = 2000;
/**
@@ -141,7 +113,8 @@ struct sk_buff *tipc_named_publish(struct publication *publ)
struct sk_buff *buf;
struct distr_item *item;
- list_add_tail(&publ->local_list, &publ_lists[publ->scope]->list);
+ list_add_tail(&publ->local_list,
+ &tipc_nametbl->publ_list[publ->scope]);
if (publ->scope == TIPC_NODE_SCOPE)
return NULL;
@@ -188,7 +161,7 @@ struct sk_buff *tipc_named_withdraw(struct publication *publ)
* @pls: linked list of publication items to be packed into buffer chain
*/
static void named_distribute(struct sk_buff_head *list, u32 dnode,
- struct publ_list *pls)
+ struct list_head *pls)
{
struct publication *publ;
struct sk_buff *skb = NULL;
@@ -196,7 +169,7 @@ static void named_distribute(struct sk_buff_head *list, u32 dnode,
uint msg_dsz = (tipc_node_get_mtu(dnode, 0) / ITEM_SIZE) * ITEM_SIZE;
uint msg_rem = msg_dsz;
- list_for_each_entry(publ, &pls->list, local_list) {
+ list_for_each_entry(publ, pls, local_list) {
/* Prepare next buffer: */
if (!skb) {
skb = named_prepare_buf(PUBLICATION, msg_rem, dnode);
@@ -236,8 +209,10 @@ void tipc_named_node_up(u32 dnode)
__skb_queue_head_init(&head);
read_lock_bh(&tipc_nametbl_lock);
- named_distribute(&head, dnode, &publ_cluster);
- named_distribute(&head, dnode, &publ_zone);
+ named_distribute(&head, dnode,
+ &tipc_nametbl->publ_list[TIPC_CLUSTER_SCOPE]);
+ named_distribute(&head, dnode,
+ &tipc_nametbl->publ_list[TIPC_ZONE_SCOPE]);
read_unlock_bh(&tipc_nametbl_lock);
tipc_link_xmit(&head, dnode, dnode);
@@ -427,7 +402,8 @@ void tipc_named_reinit(void)
write_lock_bh(&tipc_nametbl_lock);
for (scope = TIPC_ZONE_SCOPE; scope <= TIPC_NODE_SCOPE; scope++)
- list_for_each_entry(publ, &publ_lists[scope]->list, local_list)
+ list_for_each_entry(publ, &tipc_nametbl->publ_list[scope],
+ local_list)
publ->node = tipc_own_addr;
write_unlock_bh(&tipc_nametbl_lock);
diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
index 772be1c..df3da29 100644
--- a/net/tipc/name_table.c
+++ b/net/tipc/name_table.c
@@ -2,7 +2,7 @@
* net/tipc/name_table.c: TIPC name table code
*
* Copyright (c) 2000-2006, 2014, Ericsson AB
- * Copyright (c) 2004-2008, 2010-2011, Wind River Systems
+ * Copyright (c) 2004-2008, 2010-2014, Wind River Systems
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -103,18 +103,7 @@ struct name_seq {
spinlock_t lock;
};
-/**
- * struct name_table - table containing all existing port name publications
- * @types: pointer to fixed-sized array of name sequence lists,
- * accessed via hashing on 'type'; name sequence lists are *not* sorted
- * @local_publ_count: number of publications issued by this node
- */
-struct name_table {
- struct hlist_head *types;
- u32 local_publ_count;
-};
-
-static struct name_table table;
+struct name_table *tipc_nametbl;
DEFINE_RWLOCK(tipc_nametbl_lock);
static int hash(int x)
@@ -475,7 +464,7 @@ static struct name_seq *nametbl_find_seq(u32 type)
struct hlist_head *seq_head;
struct name_seq *ns;
- seq_head = &table.types[hash(type)];
+ seq_head = &tipc_nametbl->seq_hlist[hash(type)];
hlist_for_each_entry(ns, seq_head, ns_list) {
if (ns->type == type)
return ns;
@@ -488,6 +477,7 @@ struct publication *tipc_nametbl_insert_publ(u32 type, u32 lower, u32 upper,
u32 scope, u32 node, u32 port, u32 key)
{
struct name_seq *seq = nametbl_find_seq(type);
+ int index = hash(type);
if ((scope < TIPC_ZONE_SCOPE) || (scope > TIPC_NODE_SCOPE) ||
(lower > upper)) {
@@ -497,7 +487,8 @@ struct publication *tipc_nametbl_insert_publ(u32 type, u32 lower, u32 upper,
}
if (!seq)
- seq = tipc_nameseq_create(type, &table.types[hash(type)]);
+ seq = tipc_nameseq_create(type,
+ &tipc_nametbl->seq_hlist[index]);
if (!seq)
return NULL;
@@ -667,7 +658,7 @@ struct publication *tipc_nametbl_publish(u32 type, u32 lower, u32 upper,
struct publication *publ;
struct sk_buff *buf = NULL;
- if (table.local_publ_count >= TIPC_MAX_PUBLICATIONS) {
+ if (tipc_nametbl->local_publ_count >= TIPC_MAX_PUBLICATIONS) {
pr_warn("Publication failed, local publication limit reached (%u)\n",
TIPC_MAX_PUBLICATIONS);
return NULL;
@@ -677,7 +668,7 @@ struct publication *tipc_nametbl_publish(u32 type, u32 lower, u32 upper,
publ = tipc_nametbl_insert_publ(type, lower, upper, scope,
tipc_own_addr, port_ref, key);
if (likely(publ)) {
- table.local_publ_count++;
+ tipc_nametbl->local_publ_count++;
buf = tipc_named_publish(publ);
/* Any pending external events? */
tipc_named_process_backlog();
@@ -700,7 +691,7 @@ int tipc_nametbl_withdraw(u32 type, u32 lower, u32 ref, u32 key)
write_lock_bh(&tipc_nametbl_lock);
publ = tipc_nametbl_remove_publ(type, lower, tipc_own_addr, ref, key);
if (likely(publ)) {
- table.local_publ_count--;
+ tipc_nametbl->local_publ_count--;
buf = tipc_named_withdraw(publ);
/* Any pending external events? */
tipc_named_process_backlog();
@@ -725,12 +716,14 @@ int tipc_nametbl_withdraw(u32 type, u32 lower, u32 ref, u32 key)
void tipc_nametbl_subscribe(struct tipc_subscription *s)
{
u32 type = s->seq.type;
+ int index = hash(type);
struct name_seq *seq;
write_lock_bh(&tipc_nametbl_lock);
seq = nametbl_find_seq(type);
if (!seq)
- seq = tipc_nameseq_create(type, &table.types[hash(type)]);
+ seq = tipc_nameseq_create(type,
+ &tipc_nametbl->seq_hlist[index]);
if (seq) {
spin_lock_bh(&seq->lock);
tipc_nameseq_subscribe(seq, s);
@@ -882,7 +875,7 @@ static int nametbl_list(char *buf, int len, u32 depth_info,
lowbound = 0;
upbound = ~0;
for (i = 0; i < TIPC_NAMETBL_SIZE; i++) {
- seq_head = &table.types[i];
+ seq_head = &tipc_nametbl->seq_hlist[i];
hlist_for_each_entry(seq, seq_head, ns_list) {
ret += nameseq_list(seq, buf + ret, len - ret,
depth, seq->type,
@@ -898,7 +891,7 @@ static int nametbl_list(char *buf, int len, u32 depth_info,
}
ret += nametbl_header(buf + ret, len - ret, depth);
i = hash(type);
- seq_head = &table.types[i];
+ seq_head = &tipc_nametbl->seq_hlist[i];
hlist_for_each_entry(seq, seq_head, ns_list) {
if (seq->type == type) {
ret += nameseq_list(seq, buf + ret, len - ret,
@@ -945,12 +938,18 @@ struct sk_buff *tipc_nametbl_get(const void *req_tlv_area, int req_tlv_space)
int tipc_nametbl_init(void)
{
- table.types = kcalloc(TIPC_NAMETBL_SIZE, sizeof(struct hlist_head),
- GFP_ATOMIC);
- if (!table.types)
+ int i;
+
+ tipc_nametbl = kzalloc(sizeof(*tipc_nametbl), GFP_ATOMIC);
+ if (!tipc_nametbl)
return -ENOMEM;
- table.local_publ_count = 0;
+ for (i = 0; i < TIPC_NAMETBL_SIZE; i++)
+ INIT_HLIST_HEAD(&tipc_nametbl->seq_hlist[i]);
+
+ INIT_LIST_HEAD(&tipc_nametbl->publ_list[TIPC_ZONE_SCOPE]);
+ INIT_LIST_HEAD(&tipc_nametbl->publ_list[TIPC_CLUSTER_SCOPE]);
+ INIT_LIST_HEAD(&tipc_nametbl->publ_list[TIPC_NODE_SCOPE]);
return 0;
}
@@ -990,16 +989,17 @@ void tipc_nametbl_stop(void)
*/
write_lock_bh(&tipc_nametbl_lock);
for (i = 0; i < TIPC_NAMETBL_SIZE; i++) {
- if (hlist_empty(&table.types[i]))
+ if (hlist_empty(&tipc_nametbl->seq_hlist[i]))
continue;
- seq_head = &table.types[i];
+ seq_head = &tipc_nametbl->seq_hlist[i];
hlist_for_each_entry_safe(seq, safe, seq_head, ns_list) {
tipc_purge_publications(seq);
}
}
- kfree(table.types);
- table.types = NULL;
write_unlock_bh(&tipc_nametbl_lock);
+
+ kfree(tipc_nametbl);
+
}
static int __tipc_nl_add_nametable_publ(struct tipc_nl_msg *msg,
@@ -1113,7 +1113,7 @@ static int __tipc_nl_seq_list(struct tipc_nl_msg *msg, u32 *last_type,
i = 0;
for (; i < TIPC_NAMETBL_SIZE; i++) {
- seq_head = &table.types[i];
+ seq_head = &tipc_nametbl->seq_hlist[i];
if (*last_type) {
seq = nametbl_find_seq(*last_type);
diff --git a/net/tipc/name_table.h b/net/tipc/name_table.h
index c628778..c1fd734 100644
--- a/net/tipc/name_table.h
+++ b/net/tipc/name_table.h
@@ -43,7 +43,9 @@ struct tipc_port_list;
/*
* TIPC name types reserved for internal TIPC use (both current and planned)
*/
-#define TIPC_ZM_SRV 3 /* zone master service name type */
+#define TIPC_ZM_SRV 3 /* zone master service name type */
+#define TIPC_PUBL_SCOPE_NUM (TIPC_NODE_SCOPE + 1)
+#define TIPC_NAMETBL_SIZE 1024 /* must be a power of 2 */
/**
* struct publication - info about a published (name or) name sequence
@@ -79,8 +81,20 @@ struct publication {
struct list_head zone_list;
};
+/**
+ * struct name_table - table containing all existing port name publications
+ * @seq_hlist: name sequence hash lists
+ * @publ_list: pulication lists
+ * @local_publ_count: number of publications issued by this node
+ */
+struct name_table {
+ struct hlist_head seq_hlist[TIPC_NAMETBL_SIZE];
+ struct list_head publ_list[TIPC_PUBL_SCOPE_NUM];
+ u32 local_publ_count;
+};
extern rwlock_t tipc_nametbl_lock;
+extern struct name_table *tipc_nametbl;
int tipc_nl_name_table_dump(struct sk_buff *skb, struct netlink_callback *cb);
--
1.7.9.5
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
^ permalink raw reply related
* [PATCH net-next 3/8] tipc: ensure all name sequences are released when name table is stopped
From: Ying Xue @ 2014-12-02 7:00 UTC (permalink / raw)
To: davem; +Cc: jon.maloy, netdev, Paul.Gortmaker, tipc-discussion
In-Reply-To: <1417503630-31352-1-git-send-email-ying.xue@windriver.com>
As TIPC subscriber server is terminated before name table, no user
depends on subscription list of name sequence when name table is
stopped. Therefore, all name sequences stored in name table should
be released whatever their subscriptions lists are empty or not,
otherwise, memory leak might happen.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
---
net/tipc/name_table.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
index df3da29..ba0ee3e 100644
--- a/net/tipc/name_table.c
+++ b/net/tipc/name_table.c
@@ -964,10 +964,6 @@ static void tipc_purge_publications(struct name_seq *seq)
struct sub_seq *sseq;
struct name_info *info;
- if (!seq->sseqs) {
- nameseq_delete_empty(seq);
- return;
- }
sseq = seq->sseqs;
info = sseq->info;
list_for_each_entry_safe(publ, safe, &info->zone_list, zone_list) {
@@ -975,6 +971,9 @@ static void tipc_purge_publications(struct name_seq *seq)
publ->ref, publ->key);
kfree(publ);
}
+ hlist_del_init(&seq->ns_list);
+ kfree(seq->sseqs);
+ kfree(seq);
}
void tipc_nametbl_stop(void)
--
1.7.9.5
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
^ permalink raw reply related
* [PATCH net-next 4/8] tipc: ensure all name sequences are properly protected with its lock
From: Ying Xue @ 2014-12-02 7:00 UTC (permalink / raw)
To: davem; +Cc: jon.maloy, netdev, Paul.Gortmaker, tipc-discussion
In-Reply-To: <1417503630-31352-1-git-send-email-ying.xue@windriver.com>
TIPC internally created a name table which is used to store name
sequences. Now there is a read-write lock - tipc_nametbl_lock to
protect the table, and each name sequence saved in the table is
protected with its private lock. When a name sequence is inserted
or removed to or from the table, its members might need to change.
Therefore, in normal case, the two locks must be held while TIPC
operates the table. However, there are still several places where
we only hold tipc_nametbl_lock without proprerly obtaining name
sequence lock, which might cause the corruption of name sequence.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
---
net/tipc/name_table.c | 48 +++++++++++++++++++++++++++---------------------
1 file changed, 27 insertions(+), 21 deletions(-)
diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
index ba0ee3e..0d61f58 100644
--- a/net/tipc/name_table.c
+++ b/net/tipc/name_table.c
@@ -172,18 +172,6 @@ static struct name_seq *tipc_nameseq_create(u32 type, struct hlist_head *seq_hea
return nseq;
}
-/*
- * nameseq_delete_empty - deletes a name sequence structure if now unused
- */
-static void nameseq_delete_empty(struct name_seq *seq)
-{
- if (!seq->first_free && list_empty(&seq->subscriptions)) {
- hlist_del_init(&seq->ns_list);
- kfree(seq->sseqs);
- kfree(seq);
- }
-}
-
/**
* nameseq_find_subseq - find sub-sequence (if any) matching a name instance
*
@@ -476,6 +464,7 @@ static struct name_seq *nametbl_find_seq(u32 type)
struct publication *tipc_nametbl_insert_publ(u32 type, u32 lower, u32 upper,
u32 scope, u32 node, u32 port, u32 key)
{
+ struct publication *publ;
struct name_seq *seq = nametbl_find_seq(type);
int index = hash(type);
@@ -492,8 +481,11 @@ struct publication *tipc_nametbl_insert_publ(u32 type, u32 lower, u32 upper,
if (!seq)
return NULL;
- return tipc_nameseq_insert_publ(seq, type, lower, upper,
+ spin_lock_bh(&seq->lock);
+ publ = tipc_nameseq_insert_publ(seq, type, lower, upper,
scope, node, port, key);
+ spin_unlock_bh(&seq->lock);
+ return publ;
}
struct publication *tipc_nametbl_remove_publ(u32 type, u32 lower,
@@ -505,8 +497,16 @@ struct publication *tipc_nametbl_remove_publ(u32 type, u32 lower,
if (!seq)
return NULL;
+ spin_lock_bh(&seq->lock);
publ = tipc_nameseq_remove_publ(seq, lower, node, ref, key);
- nameseq_delete_empty(seq);
+ if (!seq->first_free && list_empty(&seq->subscriptions)) {
+ hlist_del_init(&seq->ns_list);
+ spin_unlock_bh(&seq->lock);
+ kfree(seq->sseqs);
+ kfree(seq);
+ return publ;
+ }
+ spin_unlock_bh(&seq->lock);
return publ;
}
@@ -539,10 +539,10 @@ u32 tipc_nametbl_translate(u32 type, u32 instance, u32 *destnode)
seq = nametbl_find_seq(type);
if (unlikely(!seq))
goto not_found;
+ spin_lock_bh(&seq->lock);
sseq = nameseq_find_subseq(seq, instance);
if (unlikely(!sseq))
- goto not_found;
- spin_lock_bh(&seq->lock);
+ goto no_match;
info = sseq->info;
/* Closest-First Algorithm */
@@ -624,7 +624,6 @@ int tipc_nametbl_mc_translate(u32 type, u32 lower, u32 upper, u32 limit,
goto exit;
spin_lock_bh(&seq->lock);
-
sseq = seq->sseqs + nameseq_locate_subseq(seq, lower);
sseq_stop = seq->sseqs + seq->first_free;
for (; sseq != sseq_stop; sseq++) {
@@ -642,7 +641,6 @@ int tipc_nametbl_mc_translate(u32 type, u32 lower, u32 upper, u32 limit,
if (info->cluster_list_size != info->node_list_size)
res = 1;
}
-
spin_unlock_bh(&seq->lock);
exit:
read_unlock_bh(&tipc_nametbl_lock);
@@ -747,8 +745,14 @@ void tipc_nametbl_unsubscribe(struct tipc_subscription *s)
if (seq != NULL) {
spin_lock_bh(&seq->lock);
list_del_init(&s->nameseq_list);
- spin_unlock_bh(&seq->lock);
- nameseq_delete_empty(seq);
+ if (!seq->first_free && list_empty(&seq->subscriptions)) {
+ hlist_del_init(&seq->ns_list);
+ spin_unlock_bh(&seq->lock);
+ kfree(seq->sseqs);
+ kfree(seq);
+ } else {
+ spin_unlock_bh(&seq->lock);
+ }
}
write_unlock_bh(&tipc_nametbl_lock);
}
@@ -964,6 +968,7 @@ static void tipc_purge_publications(struct name_seq *seq)
struct sub_seq *sseq;
struct name_info *info;
+ spin_lock_bh(&seq->lock);
sseq = seq->sseqs;
info = sseq->info;
list_for_each_entry_safe(publ, safe, &info->zone_list, zone_list) {
@@ -972,6 +977,8 @@ static void tipc_purge_publications(struct name_seq *seq)
kfree(publ);
}
hlist_del_init(&seq->ns_list);
+ spin_lock_bh(&seq->lock);
+
kfree(seq->sseqs);
kfree(seq);
}
@@ -1127,7 +1134,6 @@ static int __tipc_nl_seq_list(struct tipc_nl_msg *msg, u32 *last_type,
hlist_for_each_entry_from(seq, ns_list) {
spin_lock_bh(&seq->lock);
-
err = __tipc_nl_subseq_list(msg, seq, last_lower,
last_publ);
--
1.7.9.5
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
^ permalink raw reply related
* [PATCH net-next 5/8] tipc: any name table member must be protected under name table lock
From: Ying Xue @ 2014-12-02 7:00 UTC (permalink / raw)
To: davem; +Cc: jon.maloy, netdev, Paul.Gortmaker, tipc-discussion
In-Reply-To: <1417503630-31352-1-git-send-email-ying.xue@windriver.com>
As tipc_nametbl_lock is used to protect name_table structure, the lock
must be held while all members of name_table structure are accessed.
However, the lock is not obtained while a member of name_table
structure - local_publ_count is read in tipc_nametbl_publish(), as
a consequence, an inconsistent value of local_publ_count might be got.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
---
net/tipc/name_table.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
index 0d61f58..93bac40 100644
--- a/net/tipc/name_table.c
+++ b/net/tipc/name_table.c
@@ -656,13 +656,14 @@ struct publication *tipc_nametbl_publish(u32 type, u32 lower, u32 upper,
struct publication *publ;
struct sk_buff *buf = NULL;
+ write_lock_bh(&tipc_nametbl_lock);
if (tipc_nametbl->local_publ_count >= TIPC_MAX_PUBLICATIONS) {
pr_warn("Publication failed, local publication limit reached (%u)\n",
TIPC_MAX_PUBLICATIONS);
+ write_unlock_bh(&tipc_nametbl_lock);
return NULL;
}
- write_lock_bh(&tipc_nametbl_lock);
publ = tipc_nametbl_insert_publ(type, lower, upper, scope,
tipc_own_addr, port_ref, key);
if (likely(publ)) {
--
1.7.9.5
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
^ permalink raw reply related
* [PATCH net-next 6/8] tipc: simplify relationship between name table lock and node lock
From: Ying Xue @ 2014-12-02 7:00 UTC (permalink / raw)
To: davem; +Cc: jon.maloy, netdev, Paul.Gortmaker, tipc-discussion
In-Reply-To: <1417503630-31352-1-git-send-email-ying.xue@windriver.com>
When tipc name sequence is published, name table lock is released
before name sequence buffer is delivered to remote nodes through its
underlying unicast links. However, when name sequence is withdrawn,
the name table lock is held until the transmission of the removal
message of name sequence is finished. During the process, node lock
is nested in name table lock. To prevent node lock from being nested
in name table lock, while withdrawing name, we should adopt the same
locking policy of publishing name sequence: name table lock should
be released before message is sent.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
---
net/tipc/name_table.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
index 93bac40..bc3e7ed 100644
--- a/net/tipc/name_table.c
+++ b/net/tipc/name_table.c
@@ -685,27 +685,28 @@ struct publication *tipc_nametbl_publish(u32 type, u32 lower, u32 upper,
int tipc_nametbl_withdraw(u32 type, u32 lower, u32 ref, u32 key)
{
struct publication *publ;
- struct sk_buff *buf;
+ struct sk_buff *skb = NULL;
write_lock_bh(&tipc_nametbl_lock);
publ = tipc_nametbl_remove_publ(type, lower, tipc_own_addr, ref, key);
if (likely(publ)) {
tipc_nametbl->local_publ_count--;
- buf = tipc_named_withdraw(publ);
+ skb = tipc_named_withdraw(publ);
/* Any pending external events? */
tipc_named_process_backlog();
- write_unlock_bh(&tipc_nametbl_lock);
list_del_init(&publ->pport_list);
kfree(publ);
+ } else {
+ pr_err("Unable to remove local publication\n"
+ "(type=%u, lower=%u, ref=%u, key=%u)\n",
+ type, lower, ref, key);
+ }
+ write_unlock_bh(&tipc_nametbl_lock);
- if (buf)
- named_cluster_distribute(buf);
+ if (skb) {
+ named_cluster_distribute(skb);
return 1;
}
- write_unlock_bh(&tipc_nametbl_lock);
- pr_err("Unable to remove local publication\n"
- "(type=%u, lower=%u, ref=%u, key=%u)\n",
- type, lower, ref, key);
return 0;
}
--
1.7.9.5
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
^ permalink raw reply related
* [PATCH net-next 7/8] tipc: remove unnecessary INIT_LIST_HEAD
From: Ying Xue @ 2014-12-02 7:00 UTC (permalink / raw)
To: davem; +Cc: jon.maloy, netdev, Paul.Gortmaker, tipc-discussion
In-Reply-To: <1417503630-31352-1-git-send-email-ying.xue@windriver.com>
When a list_head variable is seen as a new entry to be added to a
list head, it's unnecessary to be initialized with INIT_LIST_HEAD().
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
---
net/tipc/name_table.c | 2 --
net/tipc/subscr.c | 1 -
2 files changed, 3 deletions(-)
diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
index bc3e7ed..3c2e0c3 100644
--- a/net/tipc/name_table.c
+++ b/net/tipc/name_table.c
@@ -131,9 +131,7 @@ static struct publication *publ_create(u32 type, u32 lower, u32 upper,
publ->node = node;
publ->ref = port_ref;
publ->key = key;
- INIT_LIST_HEAD(&publ->local_list);
INIT_LIST_HEAD(&publ->pport_list);
- INIT_LIST_HEAD(&publ->nodesub_list);
return publ;
}
diff --git a/net/tipc/subscr.c b/net/tipc/subscr.c
index 31b5cb2..0344206 100644
--- a/net/tipc/subscr.c
+++ b/net/tipc/subscr.c
@@ -305,7 +305,6 @@ static int subscr_subscribe(struct tipc_subscr *s,
kfree(sub);
return -EINVAL;
}
- INIT_LIST_HEAD(&sub->nameseq_list);
list_add(&sub->subscription_list, &subscriber->subscription_list);
sub->subscriber = subscriber;
sub->swap = swap;
--
1.7.9.5
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
^ permalink raw reply related
* [PATCH net-next 8/8] tipc: convert name table read-write lock to RCU
From: Ying Xue @ 2014-12-02 7:00 UTC (permalink / raw)
To: davem; +Cc: jon.maloy, netdev, Paul.Gortmaker, tipc-discussion
In-Reply-To: <1417503630-31352-1-git-send-email-ying.xue@windriver.com>
Convert tipc name table read-write lock to RCU. After this change,
a new spin lock is used to protect name table on write side while
RCU is applied on read side.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
---
include/linux/rculist.h | 9 +++++
net/tipc/name_distr.c | 28 +++++++--------
net/tipc/name_table.c | 87 +++++++++++++++++++++++------------------------
net/tipc/name_table.h | 4 ++-
4 files changed, 69 insertions(+), 59 deletions(-)
diff --git a/include/linux/rculist.h b/include/linux/rculist.h
index 372ad5e..aa79b3c 100644
--- a/include/linux/rculist.h
+++ b/include/linux/rculist.h
@@ -542,6 +542,15 @@ static inline void hlist_add_behind_rcu(struct hlist_node *n,
pos = hlist_entry_safe(rcu_dereference_bh((pos)->member.next),\
typeof(*(pos)), member))
+/**
+ * hlist_for_each_entry_from_rcu - iterate over a hlist continuing from current point
+ * @pos: the type * to use as a loop cursor.
+ * @member: the name of the hlist_node within the struct.
+ */
+#define hlist_for_each_entry_from_rcu(pos, member) \
+ for (; pos; \
+ pos = hlist_entry_safe(rcu_dereference((pos)->member.next),\
+ typeof(*(pos)), member))
#endif /* __KERNEL__ */
#endif
diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
index ed00929..ba6083d 100644
--- a/net/tipc/name_distr.c
+++ b/net/tipc/name_distr.c
@@ -113,8 +113,8 @@ struct sk_buff *tipc_named_publish(struct publication *publ)
struct sk_buff *buf;
struct distr_item *item;
- list_add_tail(&publ->local_list,
- &tipc_nametbl->publ_list[publ->scope]);
+ list_add_tail_rcu(&publ->local_list,
+ &tipc_nametbl->publ_list[publ->scope]);
if (publ->scope == TIPC_NODE_SCOPE)
return NULL;
@@ -208,12 +208,12 @@ void tipc_named_node_up(u32 dnode)
__skb_queue_head_init(&head);
- read_lock_bh(&tipc_nametbl_lock);
+ rcu_read_lock();
named_distribute(&head, dnode,
&tipc_nametbl->publ_list[TIPC_CLUSTER_SCOPE]);
named_distribute(&head, dnode,
&tipc_nametbl->publ_list[TIPC_ZONE_SCOPE]);
- read_unlock_bh(&tipc_nametbl_lock);
+ rcu_read_unlock();
tipc_link_xmit(&head, dnode, dnode);
}
@@ -260,12 +260,12 @@ static void tipc_publ_purge(struct publication *publ, u32 addr)
{
struct publication *p;
- write_lock_bh(&tipc_nametbl_lock);
+ spin_lock_bh(&tipc_nametbl_lock);
p = tipc_nametbl_remove_publ(publ->type, publ->lower,
publ->node, publ->ref, publ->key);
if (p)
tipc_publ_unsubscribe(p, addr);
- write_unlock_bh(&tipc_nametbl_lock);
+ spin_unlock_bh(&tipc_nametbl_lock);
if (p != publ) {
pr_err("Unable to remove publication from failed node\n"
@@ -274,7 +274,7 @@ static void tipc_publ_purge(struct publication *publ, u32 addr)
publ->key);
}
- kfree(p);
+ kfree_rcu(p, rcu);
}
void tipc_publ_notify(struct list_head *nsub_list, u32 addr)
@@ -311,7 +311,7 @@ static bool tipc_update_nametbl(struct distr_item *i, u32 node, u32 dtype)
ntohl(i->key));
if (publ) {
tipc_publ_unsubscribe(publ, node);
- kfree(publ);
+ kfree_rcu(publ, rcu);
return true;
}
} else {
@@ -376,14 +376,14 @@ void tipc_named_rcv(struct sk_buff *buf)
u32 count = msg_data_sz(msg) / ITEM_SIZE;
u32 node = msg_orignode(msg);
- write_lock_bh(&tipc_nametbl_lock);
+ spin_lock_bh(&tipc_nametbl_lock);
while (count--) {
if (!tipc_update_nametbl(item, node, msg_type(msg)))
tipc_named_add_backlog(item, msg_type(msg), node);
item++;
}
tipc_named_process_backlog();
- write_unlock_bh(&tipc_nametbl_lock);
+ spin_unlock_bh(&tipc_nametbl_lock);
kfree_skb(buf);
}
@@ -399,12 +399,12 @@ void tipc_named_reinit(void)
struct publication *publ;
int scope;
- write_lock_bh(&tipc_nametbl_lock);
+ spin_lock_bh(&tipc_nametbl_lock);
for (scope = TIPC_ZONE_SCOPE; scope <= TIPC_NODE_SCOPE; scope++)
- list_for_each_entry(publ, &tipc_nametbl->publ_list[scope],
- local_list)
+ list_for_each_entry_rcu(publ, &tipc_nametbl->publ_list[scope],
+ local_list)
publ->node = tipc_own_addr;
- write_unlock_bh(&tipc_nametbl_lock);
+ spin_unlock_bh(&tipc_nametbl_lock);
}
diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
index 3c2e0c3..aafa684c 100644
--- a/net/tipc/name_table.c
+++ b/net/tipc/name_table.c
@@ -92,6 +92,7 @@ struct sub_seq {
* @ns_list: links to adjacent name sequences in hash chain
* @subscriptions: list of subscriptions for this 'type'
* @lock: spinlock controlling access to publication lists of all sub-sequences
+ * @rcu: RCU callback head used for deferred freeing
*/
struct name_seq {
u32 type;
@@ -101,10 +102,11 @@ struct name_seq {
struct hlist_node ns_list;
struct list_head subscriptions;
spinlock_t lock;
+ struct rcu_head rcu;
};
struct name_table *tipc_nametbl;
-DEFINE_RWLOCK(tipc_nametbl_lock);
+DEFINE_SPINLOCK(tipc_nametbl_lock);
static int hash(int x)
{
@@ -166,7 +168,7 @@ static struct name_seq *tipc_nameseq_create(u32 type, struct hlist_head *seq_hea
nseq->alloc = 1;
INIT_HLIST_NODE(&nseq->ns_list);
INIT_LIST_HEAD(&nseq->subscriptions);
- hlist_add_head(&nseq->ns_list, seq_head);
+ hlist_add_head_rcu(&nseq->ns_list, seq_head);
return nseq;
}
@@ -451,7 +453,7 @@ static struct name_seq *nametbl_find_seq(u32 type)
struct name_seq *ns;
seq_head = &tipc_nametbl->seq_hlist[hash(type)];
- hlist_for_each_entry(ns, seq_head, ns_list) {
+ hlist_for_each_entry_rcu(ns, seq_head, ns_list) {
if (ns->type == type)
return ns;
}
@@ -498,10 +500,10 @@ struct publication *tipc_nametbl_remove_publ(u32 type, u32 lower,
spin_lock_bh(&seq->lock);
publ = tipc_nameseq_remove_publ(seq, lower, node, ref, key);
if (!seq->first_free && list_empty(&seq->subscriptions)) {
- hlist_del_init(&seq->ns_list);
- spin_unlock_bh(&seq->lock);
+ hlist_del_init_rcu(&seq->ns_list);
kfree(seq->sseqs);
- kfree(seq);
+ spin_unlock_bh(&seq->lock);
+ kfree_rcu(seq, rcu);
return publ;
}
spin_unlock_bh(&seq->lock);
@@ -533,7 +535,7 @@ u32 tipc_nametbl_translate(u32 type, u32 instance, u32 *destnode)
if (!tipc_in_scope(*destnode, tipc_own_addr))
return 0;
- read_lock_bh(&tipc_nametbl_lock);
+ rcu_read_lock();
seq = nametbl_find_seq(type);
if (unlikely(!seq))
goto not_found;
@@ -590,7 +592,7 @@ u32 tipc_nametbl_translate(u32 type, u32 instance, u32 *destnode)
no_match:
spin_unlock_bh(&seq->lock);
not_found:
- read_unlock_bh(&tipc_nametbl_lock);
+ rcu_read_unlock();
*destnode = node;
return ref;
}
@@ -616,7 +618,7 @@ int tipc_nametbl_mc_translate(u32 type, u32 lower, u32 upper, u32 limit,
struct name_info *info;
int res = 0;
- read_lock_bh(&tipc_nametbl_lock);
+ rcu_read_lock();
seq = nametbl_find_seq(type);
if (!seq)
goto exit;
@@ -641,7 +643,7 @@ int tipc_nametbl_mc_translate(u32 type, u32 lower, u32 upper, u32 limit,
}
spin_unlock_bh(&seq->lock);
exit:
- read_unlock_bh(&tipc_nametbl_lock);
+ rcu_read_unlock();
return res;
}
@@ -654,11 +656,11 @@ struct publication *tipc_nametbl_publish(u32 type, u32 lower, u32 upper,
struct publication *publ;
struct sk_buff *buf = NULL;
- write_lock_bh(&tipc_nametbl_lock);
+ spin_lock_bh(&tipc_nametbl_lock);
if (tipc_nametbl->local_publ_count >= TIPC_MAX_PUBLICATIONS) {
pr_warn("Publication failed, local publication limit reached (%u)\n",
TIPC_MAX_PUBLICATIONS);
- write_unlock_bh(&tipc_nametbl_lock);
+ spin_unlock_bh(&tipc_nametbl_lock);
return NULL;
}
@@ -670,7 +672,7 @@ struct publication *tipc_nametbl_publish(u32 type, u32 lower, u32 upper,
/* Any pending external events? */
tipc_named_process_backlog();
}
- write_unlock_bh(&tipc_nametbl_lock);
+ spin_unlock_bh(&tipc_nametbl_lock);
if (buf)
named_cluster_distribute(buf);
@@ -685,7 +687,7 @@ int tipc_nametbl_withdraw(u32 type, u32 lower, u32 ref, u32 key)
struct publication *publ;
struct sk_buff *skb = NULL;
- write_lock_bh(&tipc_nametbl_lock);
+ spin_lock_bh(&tipc_nametbl_lock);
publ = tipc_nametbl_remove_publ(type, lower, tipc_own_addr, ref, key);
if (likely(publ)) {
tipc_nametbl->local_publ_count--;
@@ -693,13 +695,13 @@ int tipc_nametbl_withdraw(u32 type, u32 lower, u32 ref, u32 key)
/* Any pending external events? */
tipc_named_process_backlog();
list_del_init(&publ->pport_list);
- kfree(publ);
+ kfree_rcu(publ, rcu);
} else {
pr_err("Unable to remove local publication\n"
"(type=%u, lower=%u, ref=%u, key=%u)\n",
type, lower, ref, key);
}
- write_unlock_bh(&tipc_nametbl_lock);
+ spin_unlock_bh(&tipc_nametbl_lock);
if (skb) {
named_cluster_distribute(skb);
@@ -717,7 +719,7 @@ void tipc_nametbl_subscribe(struct tipc_subscription *s)
int index = hash(type);
struct name_seq *seq;
- write_lock_bh(&tipc_nametbl_lock);
+ spin_lock_bh(&tipc_nametbl_lock);
seq = nametbl_find_seq(type);
if (!seq)
seq = tipc_nameseq_create(type,
@@ -730,7 +732,7 @@ void tipc_nametbl_subscribe(struct tipc_subscription *s)
pr_warn("Failed to create subscription for {%u,%u,%u}\n",
s->seq.type, s->seq.lower, s->seq.upper);
}
- write_unlock_bh(&tipc_nametbl_lock);
+ spin_unlock_bh(&tipc_nametbl_lock);
}
/**
@@ -740,24 +742,23 @@ void tipc_nametbl_unsubscribe(struct tipc_subscription *s)
{
struct name_seq *seq;
- write_lock_bh(&tipc_nametbl_lock);
+ spin_lock_bh(&tipc_nametbl_lock);
seq = nametbl_find_seq(s->seq.type);
if (seq != NULL) {
spin_lock_bh(&seq->lock);
list_del_init(&s->nameseq_list);
if (!seq->first_free && list_empty(&seq->subscriptions)) {
- hlist_del_init(&seq->ns_list);
- spin_unlock_bh(&seq->lock);
+ hlist_del_init_rcu(&seq->ns_list);
kfree(seq->sseqs);
- kfree(seq);
+ spin_unlock_bh(&seq->lock);
+ kfree_rcu(seq, rcu);
} else {
spin_unlock_bh(&seq->lock);
}
}
- write_unlock_bh(&tipc_nametbl_lock);
+ spin_unlock_bh(&tipc_nametbl_lock);
}
-
/**
* subseq_list - print specified sub-sequence contents into the given buffer
*/
@@ -880,7 +881,7 @@ static int nametbl_list(char *buf, int len, u32 depth_info,
upbound = ~0;
for (i = 0; i < TIPC_NAMETBL_SIZE; i++) {
seq_head = &tipc_nametbl->seq_hlist[i];
- hlist_for_each_entry(seq, seq_head, ns_list) {
+ hlist_for_each_entry_rcu(seq, seq_head, ns_list) {
ret += nameseq_list(seq, buf + ret, len - ret,
depth, seq->type,
lowbound, upbound, i);
@@ -896,7 +897,7 @@ static int nametbl_list(char *buf, int len, u32 depth_info,
ret += nametbl_header(buf + ret, len - ret, depth);
i = hash(type);
seq_head = &tipc_nametbl->seq_hlist[i];
- hlist_for_each_entry(seq, seq_head, ns_list) {
+ hlist_for_each_entry_rcu(seq, seq_head, ns_list) {
if (seq->type == type) {
ret += nameseq_list(seq, buf + ret, len - ret,
depth, type,
@@ -928,11 +929,11 @@ struct sk_buff *tipc_nametbl_get(const void *req_tlv_area, int req_tlv_space)
pb = TLV_DATA(rep_tlv);
pb_len = ULTRA_STRING_MAX_LEN;
argv = (struct tipc_name_table_query *)TLV_DATA(req_tlv_area);
- read_lock_bh(&tipc_nametbl_lock);
+ rcu_read_lock();
str_len = nametbl_list(pb, pb_len, ntohl(argv->depth),
ntohl(argv->type),
ntohl(argv->lowbound), ntohl(argv->upbound));
- read_unlock_bh(&tipc_nametbl_lock);
+ rcu_read_unlock();
str_len += 1; /* for "\0" */
skb_put(buf, TLV_SPACE(str_len));
TLV_SET(rep_tlv, TIPC_TLV_ULTRA_STRING, NULL, str_len);
@@ -974,13 +975,13 @@ static void tipc_purge_publications(struct name_seq *seq)
list_for_each_entry_safe(publ, safe, &info->zone_list, zone_list) {
tipc_nametbl_remove_publ(publ->type, publ->lower, publ->node,
publ->ref, publ->key);
- kfree(publ);
+ kfree_rcu(publ, rcu);
}
- hlist_del_init(&seq->ns_list);
+ hlist_del_init_rcu(&seq->ns_list);
+ kfree(seq->sseqs);
spin_lock_bh(&seq->lock);
- kfree(seq->sseqs);
- kfree(seq);
+ kfree_rcu(seq, rcu);
}
void tipc_nametbl_stop(void)
@@ -988,22 +989,22 @@ void tipc_nametbl_stop(void)
u32 i;
struct name_seq *seq;
struct hlist_head *seq_head;
- struct hlist_node *safe;
/* Verify name table is empty and purge any lingering
* publications, then release the name table
*/
- write_lock_bh(&tipc_nametbl_lock);
+ spin_lock_bh(&tipc_nametbl_lock);
for (i = 0; i < TIPC_NAMETBL_SIZE; i++) {
if (hlist_empty(&tipc_nametbl->seq_hlist[i]))
continue;
seq_head = &tipc_nametbl->seq_hlist[i];
- hlist_for_each_entry_safe(seq, safe, seq_head, ns_list) {
+ hlist_for_each_entry_rcu(seq, seq_head, ns_list) {
tipc_purge_publications(seq);
}
}
- write_unlock_bh(&tipc_nametbl_lock);
+ spin_unlock_bh(&tipc_nametbl_lock);
+ synchronize_net();
kfree(tipc_nametbl);
}
@@ -1109,7 +1110,7 @@ static int __tipc_nl_seq_list(struct tipc_nl_msg *msg, u32 *last_type,
u32 *last_lower, u32 *last_publ)
{
struct hlist_head *seq_head;
- struct name_seq *seq;
+ struct name_seq *seq = NULL;
int err;
int i;
@@ -1126,13 +1127,13 @@ static int __tipc_nl_seq_list(struct tipc_nl_msg *msg, u32 *last_type,
if (!seq)
return -EPIPE;
} else {
- seq = hlist_entry_safe((seq_head)->first,
- struct name_seq, ns_list);
+ hlist_for_each_entry_rcu(seq, seq_head, ns_list)
+ break;
if (!seq)
continue;
}
- hlist_for_each_entry_from(seq, ns_list) {
+ hlist_for_each_entry_from_rcu(seq, ns_list) {
spin_lock_bh(&seq->lock);
err = __tipc_nl_subseq_list(msg, seq, last_lower,
last_publ);
@@ -1165,8 +1166,7 @@ int tipc_nl_name_table_dump(struct sk_buff *skb, struct netlink_callback *cb)
msg.portid = NETLINK_CB(cb->skb).portid;
msg.seq = cb->nlh->nlmsg_seq;
- read_lock_bh(&tipc_nametbl_lock);
-
+ rcu_read_lock();
err = __tipc_nl_seq_list(&msg, &last_type, &last_lower, &last_publ);
if (!err) {
done = 1;
@@ -1179,8 +1179,7 @@ int tipc_nl_name_table_dump(struct sk_buff *skb, struct netlink_callback *cb)
*/
cb->prev_seq = 1;
}
-
- read_unlock_bh(&tipc_nametbl_lock);
+ rcu_read_unlock();
cb->args[0] = last_type;
cb->args[1] = last_lower;
diff --git a/net/tipc/name_table.h b/net/tipc/name_table.h
index c1fd734..5f0dee9 100644
--- a/net/tipc/name_table.h
+++ b/net/tipc/name_table.h
@@ -62,6 +62,7 @@ struct tipc_port_list;
* @node_list: adjacent matching name seq publications with >= node scope
* @cluster_list: adjacent matching name seq publications with >= cluster scope
* @zone_list: adjacent matching name seq publications with >= zone scope
+ * @rcu: RCU callback head used for deferred freeing
*
* Note that the node list, cluster list, and zone list are circular lists.
*/
@@ -79,6 +80,7 @@ struct publication {
struct list_head node_list;
struct list_head cluster_list;
struct list_head zone_list;
+ struct rcu_head rcu;
};
/**
@@ -93,7 +95,7 @@ struct name_table {
u32 local_publ_count;
};
-extern rwlock_t tipc_nametbl_lock;
+extern spinlock_t tipc_nametbl_lock;
extern struct name_table *tipc_nametbl;
int tipc_nl_name_table_dump(struct sk_buff *skb, struct netlink_callback *cb);
--
1.7.9.5
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
^ permalink raw reply related
* [PATCH net-next 0/8] tipc: convert name table read-write lock to RCU
From: Ying Xue @ 2014-12-02 7:00 UTC (permalink / raw)
To: davem
Cc: jon.maloy, Paul.Gortmaker, erik.hugne, richard.alpe, tero.aho,
netdev, tipc-discussion
Now TIPC name table is statically allocated and is protected with a
Read-Write lock. To enhance the performance of TIPC name table lookup,
we are going to involve RCU lock to protect the name table. As a
consequence, it becomes lockless to concurrently look up name table on
read side. However, before the conversion can be successfully made,
the following two things must be first done:
- change allocation way of name table from static to dynamic
- fix several incorrect locking policy issues
Ying Xue (8):
tipc: remove size variable from publ_list struct
tipc: make name table allocated dynamically
tipc: ensure all name sequences are released when name table is
stopped
tipc: ensure all name sequences are properly protected with its lock
tipc: any name table member must be protected under name table lock
tipc: simplify relationship between name table lock and node lock
tipc: remove unnecessary INIT_LIST_HEAD
tipc: convert name table read-write lock to RCU
include/linux/rculist.h | 9 +++
net/tipc/name_distr.c | 83 +++++++------------
net/tipc/name_table.c | 202 ++++++++++++++++++++++++-----------------------
net/tipc/name_table.h | 20 ++++-
net/tipc/subscr.c | 1 -
5 files changed, 157 insertions(+), 158 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH net-next 1/8] tipc: remove size variable from publ_list struct
From: Ying Xue @ 2014-12-02 7:00 UTC (permalink / raw)
To: davem
Cc: jon.maloy, Paul.Gortmaker, erik.hugne, richard.alpe, tero.aho,
netdev, tipc-discussion
In-Reply-To: <1417503630-31352-1-git-send-email-ying.xue@windriver.com>
The size variable is introduced in publ_list struct to help us exactly
calculate SKB buffer sizes needed by publications when all publications
in name table are delivered in bulk in named_distribute(). But if
publication SKB buffer size is assumed to MTU, the size variable in
publ_list struct can be completely eliminated at the cost of wasting
a bit memory space for last SKB.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Tero Aho <tero.aho@coriant.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
---
net/tipc/name_distr.c | 19 +++++++------------
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
index 56248db..628cd85 100644
--- a/net/tipc/name_distr.c
+++ b/net/tipc/name_distr.c
@@ -41,26 +41,21 @@
/**
* struct publ_list - list of publications made by this node
* @list: circular list of publications
- * @list_size: number of entries in list
*/
struct publ_list {
struct list_head list;
- u32 size;
};
static struct publ_list publ_zone = {
.list = LIST_HEAD_INIT(publ_zone.list),
- .size = 0,
};
static struct publ_list publ_cluster = {
.list = LIST_HEAD_INIT(publ_cluster.list),
- .size = 0,
};
static struct publ_list publ_node = {
.list = LIST_HEAD_INIT(publ_node.list),
- .size = 0,
};
static struct publ_list *publ_lists[] = {
@@ -147,7 +142,6 @@ struct sk_buff *tipc_named_publish(struct publication *publ)
struct distr_item *item;
list_add_tail(&publ->local_list, &publ_lists[publ->scope]->list);
- publ_lists[publ->scope]->size++;
if (publ->scope == TIPC_NODE_SCOPE)
return NULL;
@@ -172,7 +166,6 @@ struct sk_buff *tipc_named_withdraw(struct publication *publ)
struct distr_item *item;
list_del(&publ->local_list);
- publ_lists[publ->scope]->size--;
if (publ->scope == TIPC_NODE_SCOPE)
return NULL;
@@ -200,16 +193,12 @@ static void named_distribute(struct sk_buff_head *list, u32 dnode,
struct publication *publ;
struct sk_buff *skb = NULL;
struct distr_item *item = NULL;
- uint dsz = pls->size * ITEM_SIZE;
uint msg_dsz = (tipc_node_get_mtu(dnode, 0) / ITEM_SIZE) * ITEM_SIZE;
- uint rem = dsz;
- uint msg_rem = 0;
+ uint msg_rem = msg_dsz;
list_for_each_entry(publ, &pls->list, local_list) {
/* Prepare next buffer: */
if (!skb) {
- msg_rem = min_t(uint, rem, msg_dsz);
- rem -= msg_rem;
skb = named_prepare_buf(PUBLICATION, msg_rem, dnode);
if (!skb) {
pr_warn("Bulk publication failure\n");
@@ -227,8 +216,14 @@ static void named_distribute(struct sk_buff_head *list, u32 dnode,
if (!msg_rem) {
__skb_queue_tail(list, skb);
skb = NULL;
+ msg_rem = msg_dsz;
}
}
+ if (skb) {
+ msg_set_size(buf_msg(skb), INT_H_SIZE + (msg_dsz - msg_rem));
+ skb_trim(skb, INT_H_SIZE + (msg_dsz - msg_rem));
+ __skb_queue_tail(list, skb);
+ }
}
/**
--
1.7.9.5
^ permalink raw reply related
* Re: Is this 32-bit NCM?
From: Eli Britstein @ 2014-12-02 7:11 UTC (permalink / raw)
To: Kevin Zhu
Cc: Enrico Mioso, Bjørn Mork, Alex Strizhevsky,
Midge Shaojun Tan, youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <547D61C0.2080904@audiocodes.com>
Maybe the FW expects some kind of checksum or crc in the padding area?
Sent from my iPhone
> On 2 בדצמ 2014, at 08:52, "Kevin Zhu" <Mingying.Zhu@audiocodes.com> wrote:
>
> OK. I will look at the windows driver and registry. I don't have any
> manual of it.
>
> 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
* [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
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