* Re: Is this 32-bit NCM?y
From: Kevin Zhu @ 2014-12-04 9:26 UTC (permalink / raw)
To: Bjørn Mork
Cc: Enrico Mioso, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <874mtbojqo.fsf@nemi.mork.no>
I will find it out. And I don't have v3.16 and I'm not going to upgrade
my OS to that. Sorry. So I would just stick to v3.13. Anyway, that size
is wrong, it should be fixed.
Regards,
Kevin
On 12/04/2014 05:19 PM, Bjørn Mork wrote:
> Kevin Zhu <Mingying.Zhu@audiocodes.com> writes:
>
>> Guys,
>>
>> After rearranging the padding, putting NCM0 right after NTH, and disable
>> ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it
>> begins to work, though there's still problem with DHCP.
> Great! But it would be good to know if _one_ of these changes is enough
> to make it work.
>
>> The DHCP packet's size becomes a large one after the TX function, which
>> is 16384, the maximum.
> You can now (from v3.16) disable the padding by setting min_tx_pkt >= tx_max.
> Something like this should do for a simple test:
>
> echo 16384 >/sys/class/net/wwan0/cdc_ncm/min_tx_pkt
>
>
> Bjørn
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] x86: bpf_jit_comp: simplify trivial boolean return
From: Joe Perches @ 2014-12-04 9:26 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David Laight, Quentin Lambert, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, x86@kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1417114175.4305.3.camel@perches.com>
On Thu, 2014-11-27 at 10:49 -0800, Joe Perches wrote:
> On Thu, 2014-11-27 at 12:25 +0000, David Laight wrote:
> > Why the change in data?
>
> btw: without gcov and using -O2
>
> $ size arch/x86/net/bpf_jit_comp.o*
> text data bss dec hex filename
> 9671 4 0 9675 25cb arch/x86/net/bpf_jit_comp.o.new
> 10679 4 0 10683 29bb arch/x86/net/bpf_jit_comp.o.old
Alexei?
Is this 10% reduction in size a good reason to change the code?
^ permalink raw reply
* Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Thomas Graf @ 2014-12-04 9:26 UTC (permalink / raw)
To: Jesse Gross
Cc: Michael S. Tsirkin, Du, Fan, Jason Wang, netdev@vger.kernel.org,
davem@davemloft.net, fw@strlen.de, dev@openvswitch.org,
Pravin Shelar
In-Reply-To: <CAEP_g=8U_w+dxUHsTH2JQ9dGNHaJp-ai8pdmrfeYBin9NZ46jQ@mail.gmail.com>
On 12/03/14 at 05:51pm, Jesse Gross wrote:
> I think it depends on where you put the PMTU check. If routing is
> happening in OVS where it is decomposed in several discrete actions
> like set MAC and decrement TTL then perhaps there is another explicit
> action to check the MTU. If it is happening in the context of the IP
> stack, then ICMP generation occurs automatically and if you get that
> if you write a flow to send a packet there. In each case, it seems
> like a flow would be steering you by way of an action to do routing so
> you would have fine grained control. I don't see this as conflicting
> with L3 ACLs in an L2 context in the same way that you don't have to
> automatically decrement the TTL.
OK, I was under the impression that you would detect L3 behaviour
desire in OVS without an explicit action. Hence the worry on wrong
classification for L3 ACLs.
Whether we mark the packet and defer the MTU check or we check right
in the action is an implementation detail in the end. I think we
agree on concept level that we need an API to control behaviour.
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Enrico Mioso @ 2014-12-04 9:28 UTC (permalink / raw)
To: Kevin Zhu
Cc: Bjørn Mork, Enrico Mioso, Eli Britstein, Alex Strizhevsky,
Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <548028A0.5000909-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2567 bytes --]
Ok - but... you can upgrade your OS to that without any effort - simply apt-get-installing the required linux-image-3.16 package plus the -extra package. It's nothing more in case.
thank you kevin, thank you Bjorn.
Enrico
On Thu, 4 Dec 2014, Kevin Zhu wrote:
> Date: Thu, 4 Dec 2014 10:26:20
> From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
> To: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> Cc: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
> Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
> Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
> Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
> "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
> "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
> "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Subject: Re: Is this 32-bit NCM?y
>
> I will find it out. And I don't have v3.16 and I'm not going to upgrade
> my OS to that. Sorry. So I would just stick to v3.13. Anyway, that size
> is wrong, it should be fixed.
>
> Regards,
> Kevin
>
> On 12/04/2014 05:19 PM, Bjørn Mork wrote:
>> Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> writes:
>>
>>> Guys,
>>>
>>> After rearranging the padding, putting NCM0 right after NTH, and disable
>>> ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it
>>> begins to work, though there's still problem with DHCP.
>> Great! But it would be good to know if _one_ of these changes is enough
>> to make it work.
>>
>>> The DHCP packet's size becomes a large one after the TX function, which
>>> is 16384, the maximum.
>> You can now (from v3.16) disable the padding by setting min_tx_pkt >= tx_max.
>> Something like this should do for a simple test:
>>
>> echo 16384 >/sys/class/net/wwan0/cdc_ncm/min_tx_pkt
>>
>>
>> Bjørn
> 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: 3.12.33 - BUG xfrm_selector_match+0x25/0x2f6
From: Jiri Slaby @ 2014-12-04 9:44 UTC (permalink / raw)
To: f.wiessner, netdev, LKML, stable
In-Reply-To: <547F2462.6040405@smart-weblications.de>
On 12/03/2014, 03:55 PM, Smart Weblications GmbH - Florian Wiessner wrote:
> [16623.095403] BUG: unable to handle kernel paging request at 00000000010600d0
> [16623.095445] IP: [<ffffffff81547767>] xfrm_selector_match+0x25/0x2f6
> [16623.095480] PGD aeaea067 PUD 85d95067 PMD 0
> [16623.095513] Oops: 0000 [#1] SMP
> [16623.095543] Modules linked in: netconsole xt_nat xt_multiport veth ip_vs_rr
...
> [16623.096062] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.12.33 #1
> [16623.096091] Hardware name: Supermicro X9SCI/X9SCA/X9SCI/X9SCA, BIOS 1.1a
> 09/28/2011
> [16623.096137] task: ffffffff81804450 ti: ffffffff817f4000 task.ti: ffffffff817f4000
> [16623.096182] RIP: 0010:[<ffffffff81547767>] [<ffffffff81547767>]
> xfrm_selector_match+0x25/0x2f6
> [16623.096233] RSP: 0018:ffff88083fc03900 EFLAGS: 00010246
> [16623.096261] RAX: 0000000000000001 RBX: ffff88083fc03a20 RCX: ffff880787fb1200
> [16623.096292] RDX: 0000000000000002 RSI: ffff88083fc03a20 RDI: 00000000010600a6
> [16623.096323] RBP: 00000000010600a6 R08: 0000000000000000 R09: ffff88083fc039a0
> [16623.096353] R10: 0000000000000000 R11: 0000000000000001 R12: ffff88083fc03a20
> [16623.096383] R13: 0000000000000001 R14: ffffffff818a9700 R15: ffffffffa01c73e0
> [16623.096414] FS: 0000000000000000(0000) GS:ffff88083fc00000(0000)
> knlGS:0000000000000000
> [16623.096469] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [16623.096498] CR2: 00000000010600d0 CR3: 0000000085f0b000 CR4: 00000000000407f0
> [16623.096528] Stack:
> [16623.096550] 0000000000000000 0000000001060002 ffff880787fb1200 ffff88083fc03a20
> [16623.096602] 0000000000000001 ffffffff81547a7c 0000000000000000 ffff8800baad5480
> [16623.096655] ffffffff81804450 ffffffff818a9700 000000003c9041bc ffffffff81547ef7
> [16623.096721] Call Trace:
> [16623.096744] <IRQ>
> [16623.096749] [<ffffffff81547a7c>] ? xfrm_sk_policy_lookup+0x44/0x9b
> [16623.096802] [<ffffffff81547ef7>] ? xfrm_lookup+0x91/0x446
> [16623.096832] [<ffffffff81541316>] ? ip_route_me_harder+0x150/0x1b0
> [16623.096865] [<ffffffffa01b6457>] ? ip_vs_route_me_harder+0x86/0x91 [ip_vs]
> [16623.096899] [<ffffffffa01b797a>] ? ip_vs_out+0x2d3/0x5bc [ip_vs]
> [16623.096930] [<ffffffff81501420>] ? ip_rcv_finish+0x2b8/0x2b8
> [16623.096959] [<ffffffff814fc2d3>] ? nf_iterate+0x42/0x80
> [16623.096989] [<ffffffff814fc37a>] ? nf_hook_slow+0x69/0xff
> [16623.097017] [<ffffffff81501420>] ? ip_rcv_finish+0x2b8/0x2b8
> [16623.097047] [<ffffffff81501744>] ? ip_local_deliver+0x6f/0x7e
> [16623.097078] [<ffffffff814d82a6>] ? __netif_receive_skb_core+0x5f0/0x66c
> [16623.097108] [<ffffffff814d84b7>] ? process_backlog+0x13e/0x13e
> [16623.097140] [<ffffffffa04b4e09>] ? br_handle_frame_finish+0x382/0x382 [bridge]
> [16623.097187] [<ffffffff814d8503>] ? netif_receive_skb+0x4c/0x7d
> [16623.097218] [<ffffffffa04b4d95>] ? br_handle_frame_finish+0x30e/0x382 [bridge]
> [16623.097265] [<ffffffffa04b4fda>] ? br_handle_frame+0x1d1/0x217 [bridge]
> [16623.097297] [<ffffffffa048e4aa>] ? bond_handle_frame+0x86/0x1bd [bonding]
> [16623.097328] [<ffffffff814d8155>] ? __netif_receive_skb_core+0x49f/0x66c
> [16623.097358] [<ffffffff814d8503>] ? netif_receive_skb+0x4c/0x7d
> [16623.097388] [<ffffffff814d9091>] ? napi_gro_receive+0x35/0x76
> [16623.097418] [<ffffffff813eae17>] ? e1000_clean_rx_irq+0x26d/0x2f5
> [16623.097448] [<ffffffff813ef48e>] ? e1000e_poll+0x65/0x23d
> [16623.097477] [<ffffffff814d8709>] ? net_rx_action+0xa2/0x1c0
...
> This happens again and again with 3.12.33
>
>
> see also: http://www.spinics.net/lists/netdev/msg306283.html
>
> is this already fixed somehow?
Hi, I doubt so, as you are the first one letting me know. Could you
check whether 3.12.30 works OK for you?
thanks,
--
js
suse labs
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Enrico Mioso @ 2014-12-04 9:53 UTC (permalink / raw)
To: Bjørn Mork
Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <874mtbojqo.fsf@nemi.mork.no>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1529 bytes --]
Guys!
Don't forget I can test it - since I have a remote machine with 3.16 kernel
and the device, at least for now.
So - Bjorn: do I need just to disable padding or do I need also to perform some
other changes? I am sorry if I ask this a little bit stupidly, but I was
alittle bit busy here.
On Thu, 4 Dec 2014, Bjørn Mork wrote:
> Date: Thu, 4 Dec 2014 10:19:11
> From: Bjørn Mork <bjorn@mork.no>
> To: Kevin Zhu <Mingying.Zhu@audiocodes.com>
> Cc: Enrico Mioso <mrkiko.rs@gmail.com>,
> Eli Britstein <Eli.Britstein@audiocodes.com>,
> 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?y
>
> Kevin Zhu <Mingying.Zhu@audiocodes.com> writes:
>
>> Guys,
>>
>> After rearranging the padding, putting NCM0 right after NTH, and disable
>> ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it
>> begins to work, though there's still problem with DHCP.
>
> Great! But it would be good to know if _one_ of these changes is enough
> to make it work.
>
>> The DHCP packet's size becomes a large one after the TX function, which
>> is 16384, the maximum.
>
> You can now (from v3.16) disable the padding by setting min_tx_pkt >= tx_max.
> Something like this should do for a simple test:
>
> echo 16384 >/sys/class/net/wwan0/cdc_ncm/min_tx_pkt
>
>
> Bjørn
>
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Bjørn Mork @ 2014-12-04 9:55 UTC (permalink / raw)
To: Kevin Zhu
Cc: Enrico Mioso, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <548028A0.5000909@audiocodes.com>
Kevin Zhu <Mingying.Zhu@audiocodes.com> writes:
> I will find it out. And I don't have v3.16 and I'm not going to upgrade
> my OS to that. Sorry. So I would just stick to v3.13.
Ouch. well, OK. I certainly hope you are at v3.13.10 or newer at
least. Otherwise we know very well what the problem is...
One of the reasons for the series that went into v3.16 was making this
sort of debugging easier, enabling on-the-fly NCM aggregation parameter
tuning. I'd certainly recommend taking advantage of it instead of
rebulding the driver every time you want to test the effect of some
minor change to the aggregation scheme. And do feel free to add more
knobs if you need them.
Bjørn
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Bjørn Mork @ 2014-12-04 10:02 UTC (permalink / raw)
To: Enrico Mioso
Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <alpine.LNX.2.03.1412041052310.3861@gmail.com>
Enrico Mioso <mrkiko.rs@gmail.com> writes:
> Guys!
> Don't forget I can test it - since I have a remote machine with 3.16
> kernel and the device, at least for now.
> So - Bjorn: do I need just to disable padding or do I need also to
> perform some other changes? I am sorry if I ask this a little bit
> stupidly, but I was alittle bit busy here.
I don't know. I just mentioned it because it is easy to test, although
the method isn't too obvious. Someone should document this somewhere.
Hey, wait... Someone did :-)
https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
Bjørn
^ permalink raw reply
* Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Michael S. Tsirkin @ 2014-12-04 10:17 UTC (permalink / raw)
To: Rick Jones
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jason Wang,
Du, Fan, fw-HFFVJYpyMKqzQB+pC5nmwQ@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
In-Reply-To: <547F5CC2.8000908-VXdhtT5mjnY@public.gmane.org>
On Wed, Dec 03, 2014 at 10:56:02AM -0800, Rick Jones wrote:
> Trying to "fake-out" an ICMP message to paper-over "devices" in the "middle"
> of same Layer2 network having different MTUs from the ends goes back to at
> least the days when people started joining FDDI networks to Ethernet
> networks with bridges rather than routers. Perhaps back even further. It
> had problems them (including not all traffic being IP), I doubt today would
> be any different.
>
> All devices in a Layer2 network must have the same MTU. (*)
>
> The only exception to that which does not lead one down a rathole is that
> you can have the MTU at the "edges" of the Layer 2 network be smaller than
> the MTU in the "middle." And then only if the middle "never" tries to talk
> itself to the edges directly.
>
> rick jones
>
> (*) Or at least any communicating device must be kept ignorant of what one
> does to have a smaller MTU in there somewhere.
What I've been pointing out is that just because something is within a VM,
we can't assume it's an edge.
--
MST
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH v3 net-next 2/2 tuntap: Increase the number of queues in tun.
From: Michael S. Tsirkin @ 2014-12-04 10:20 UTC (permalink / raw)
To: Jason Wang
Cc: Pankaj Gupta, linux-kernel, netdev, davem, dgibson, vfalico,
edumazet, vyasevic, hkchu, wuzhy, xemul, therbert, bhutchings,
xii, stephen, jiri, sergei.shtylyov
In-Reply-To: <1417661734.16500.0@smtp.corp.redhat.com>
On Thu, Dec 04, 2014 at 03:03:34AM +0008, Jason Wang wrote:
>
>
> On Wed, Dec 3, 2014 at 5:52 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >On Wed, Dec 03, 2014 at 12:49:37PM +0530, Pankaj Gupta wrote:
> >> Networking under kvm works best if we allocate a per-vCPU RX and TX
> >> queue in a virtual NIC. This requires a per-vCPU queue on the host
> >>side.
> >> It is now safe to increase the maximum number of queues.
> >> Preceding patche: 'net: allow large number of rx queues'
> >
> >s/patche/patch/
> >
> >> made sure this won't cause failures due to high order memory
> >> allocations. Increase it to 256: this is the max number of vCPUs
> >> KVM supports.
> >> Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
> >> Reviewed-by: David Gibson <dgibson@redhat.com>
> >
> >Hmm it's kind of nasty that each tun device is now using x16 memory.
> >Maybe we should look at using a flex array instead, and removing the
> >limitation altogether (e.g. make it INT_MAX)?
>
> But this only happens when IFF_MULTIQUEUE were used.
I refer to this field:
struct tun_file __rcu *tfiles[MAX_TAP_QUEUES];
if we make MAX_TAP_QUEUES 256, this will use 4K bytes,
apparently unconditionally.
> And core has vmalloc() fallback.
> So probably not a big issue?
> >
> >
> >
> >> ---
> >> drivers/net/tun.c | 9 +++++----
> >> 1 file changed, 5 insertions(+), 4 deletions(-)
> >> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> >> index e3fa65a..a19dc5f8 100644
> >> --- a/drivers/net/tun.c
> >> +++ b/drivers/net/tun.c
> >> @@ -113,10 +113,11 @@ struct tap_filter {
> >> unsigned char addr[FLT_EXACT_COUNT][ETH_ALEN];
> >> };
> >> -/* DEFAULT_MAX_NUM_RSS_QUEUES were chosen to let the rx/tx queues
> >>allocated for
> >> - * the netdevice to be fit in one page. So we can make sure the
> >>success of
> >> - * memory allocation. TODO: increase the limit. */
> >> -#define MAX_TAP_QUEUES DEFAULT_MAX_NUM_RSS_QUEUES
> >> +/* MAX_TAP_QUEUES 256 is chosen to allow rx/tx queues to be equal
> >> + * to max number of vCPUS in guest. Also, we are making sure here
> >> + * queue memory allocation do not fail.
> >
> >It's not queue memory allocation anymore, is it?
> >I would say "
> >This also helps the tfiles field fit in 4K, so the whole tun
> >device only needs an order-1 allocation.
> >"
> >
> >> + */
> >> +#define MAX_TAP_QUEUES 256
> >> #define MAX_TAP_FLOWS 4096
> >> #define TUN_FLOW_EXPIRE (3 * HZ)
> >> -- 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: Is this 32-bit NCM?y
From: Midge Shaojun Tan @ 2014-12-04 10:10 UTC (permalink / raw)
To: Enrico Mioso, Bjørn Mork
Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, youtux@gmail.com,
linux-usb@vger.kernel.org, netdev@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 2748 bytes --]
Hi all,
I test OK with kervel 3.16.4
Need disable other Ethernet network, just like eth1. (Then the DNS and route is OK)
And also need disable arp, (ifconfig wwan0 -arp up), because China UNICOM don't respond the ARP message.
With new mode switch string: /etc/usb_modeswitch.d/12d1:14fe
Please see the patch and check whether it is correct?
-----邮件原件-----
发件人: Enrico Mioso [mailto:mrkiko.rs@gmail.com]
发送时间: 2014年12月4日 17:54
收件人: Bjørn Mork
抄送: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun Tan; youtux@gmail.com; linux-usb@vger.kernel.org; netdev@vger.kernel.org
主题: Re: Is this 32-bit NCM?y
Guys!
Don't forget I can test it - since I have a remote machine with 3.16 kernel and the device, at least for now.
So - Bjorn: do I need just to disable padding or do I need also to perform some other changes? I am sorry if I ask this a little bit stupidly, but I was alittle bit busy here.
On Thu, 4 Dec 2014, Bjørn Mork wrote:
> Date: Thu, 4 Dec 2014 10:19:11
> From: Bjørn Mork <bjorn@mork.no>
> To: Kevin Zhu <Mingying.Zhu@audiocodes.com>
> Cc: Enrico Mioso <mrkiko.rs@gmail.com>,
> Eli Britstein <Eli.Britstein@audiocodes.com>,
> 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?y
>
> Kevin Zhu <Mingying.Zhu@audiocodes.com> writes:
>
>> Guys,
>>
>> After rearranging the padding, putting NCM0 right after NTH, and
>> disable ARP (FLAG_NOARP) and handling the offset alignment issue, it
>> seems it begins to work, though there's still problem with DHCP.
>
> Great! But it would be good to know if _one_ of these changes is
> enough to make it work.
>
>> The DHCP packet's size becomes a large one after the TX function,
>> which is 16384, the maximum.
>
> You can now (from v3.16) disable the padding by setting min_tx_pkt >= tx_max.
> Something like this should do for a simple test:
>
> echo 16384 >/sys/class/net/wwan0/cdc_ncm/min_tx_pkt
>
>
> Bjørn
>
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: cdc_ncm.tgz --]
[-- Type: application/x-compressed, Size: 25607 bytes --]
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Enrico Mioso @ 2014-12-04 10:24 UTC (permalink / raw)
To: Midge Shaojun Tan
Cc: Bjørn Mork, Kevin Zhu, Eli Britstein, Alex Strizhevsky,
youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <AMSPR06MB6011E001029C251790CB923EE780-MyG0ARRHH/drF+2gGhmTpL9PrO6axcR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4283 bytes --]
Congratulations!
Your modification to the driver work; the disable of padding itself alone did not.
With the modified file version I am able to use the device with no problems.
Congratulations guys.
On Thu, 4 Dec 2014, Midge Shaojun Tan wrote:
> Date: Thu, 4 Dec 2014 11:10:16
> From: Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
> To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> Cc: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
> Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
> Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
> "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
> "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
> "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Subject: Re: Is this 32-bit NCM?y
>
> Hi all,
>
> I test OK with kervel 3.16.4
> Need disable other Ethernet network, just like eth1. (Then the DNS and route is OK)
> And also need disable arp, (ifconfig wwan0 -arp up), because China UNICOM don't respond the ARP message.
> With new mode switch string: /etc/usb_modeswitch.d/12d1:14fe
> Please see the patch and check whether it is correct?
>
>
> -----邮件原件-----
> 发件人: Enrico Mioso [mailto:mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
> 发送时间: 2014年12月4日 17:54
> 收件人: Bjørn Mork
> 抄送: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun Tan; youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> 主题: Re: Is this 32-bit NCM?y
>
> Guys!
> Don't forget I can test it - since I have a remote machine with 3.16 kernel and the device, at least for now.
> So - Bjorn: do I need just to disable padding or do I need also to perform some other changes? I am sorry if I ask this a little bit stupidly, but I was alittle bit busy here.
>
>
>
>
>
> On Thu, 4 Dec 2014, Bjørn Mork wrote:
>
>> Date: Thu, 4 Dec 2014 10:19:11
>> From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
>> To: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
>> Cc: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>> Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
>> Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>> Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
>> "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>> "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
>> "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>> Subject: Re: Is this 32-bit NCM?y
>>
>> Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> writes:
>>
>>> Guys,
>>>
>>> After rearranging the padding, putting NCM0 right after NTH, and
>>> disable ARP (FLAG_NOARP) and handling the offset alignment issue, it
>>> seems it begins to work, though there's still problem with DHCP.
>>
>> Great! But it would be good to know if _one_ of these changes is
>> enough to make it work.
>>
>>> The DHCP packet's size becomes a large one after the TX function,
>>> which is 16384, the maximum.
>>
>> You can now (from v3.16) disable the padding by setting min_tx_pkt >= tx_max.
>> Something like this should do for a simple test:
>>
>> echo 16384 >/sys/class/net/wwan0/cdc_ncm/min_tx_pkt
>>
>>
>> Bjørn
>>
> 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: tulip: Remove private "strncmp"
From: Rasmus Villemoes @ 2014-12-04 10:30 UTC (permalink / raw)
To: Grant Grundler; +Cc: Rasmus Villemoes, netdev, linux-kernel
The comment says that the built-in strncmp didn't work. That is not
surprising, as apparently "str" semantics are not really what is
wanted (hint: de4x5_strncmp only stops when two different bytes are
encountered or the end is reached; not if either byte happens to be
0). de4x5_strncmp is actually a memcmp (except for the signature and
that bytes are not necessarily treated as unsigned char); since only
the boolean value of the result is used we can just replace
de4x5_strncmp with memcmp.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
Notes:
I don't know if the comment meant to say 3 bytes, or if the code
compares meaningful chunks of memory (the first three bytes of
&lp->srom span 1.5 fields, and the three bytes from (char*)&lp->srom +
0x10 are &lp->srom.{id_block_crc,reserved2,version} - it seems odd
that these chunks should ever be equal to each other and to the
enet_det[i]). Whether or not the current code works, this patch
shouldn't change the semantics, and I'd like to get rid of
de4x5_strncmp since it is not, in fact, a strncmp.
drivers/net/ethernet/dec/tulip/de4x5.c | 20 +++-----------------
1 file changed, 3 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/dec/tulip/de4x5.c b/drivers/net/ethernet/dec/tulip/de4x5.c
index cf8b6ff..badff18 100644
--- a/drivers/net/ethernet/dec/tulip/de4x5.c
+++ b/drivers/net/ethernet/dec/tulip/de4x5.c
@@ -995,7 +995,6 @@ static void de4x5_dbg_mii(struct net_device *dev, int k);
static void de4x5_dbg_media(struct net_device *dev);
static void de4x5_dbg_srom(struct de4x5_srom *p);
static void de4x5_dbg_rx(struct sk_buff *skb, int len);
-static int de4x5_strncmp(char *a, char *b, int n);
static int dc21041_infoleaf(struct net_device *dev);
static int dc21140_infoleaf(struct net_device *dev);
static int dc21142_infoleaf(struct net_device *dev);
@@ -4102,8 +4101,7 @@ get_hw_addr(struct net_device *dev)
}
/*
-** Test for enet addresses in the first 32 bytes. The built-in strncmp
-** didn't seem to work here...?
+** Test for enet addresses in the first 32 bytes.
*/
static int
de4x5_bad_srom(struct de4x5_private *lp)
@@ -4111,8 +4109,8 @@ de4x5_bad_srom(struct de4x5_private *lp)
int i, status = 0;
for (i = 0; i < ARRAY_SIZE(enet_det); i++) {
- if (!de4x5_strncmp((char *)&lp->srom, (char *)&enet_det[i], 3) &&
- !de4x5_strncmp((char *)&lp->srom+0x10, (char *)&enet_det[i], 3)) {
+ if (!memcmp(&lp->srom, &enet_det[i], 3) &&
+ !memcmp((char *)&lp->srom+0x10, &enet_det[i], 3)) {
if (i == 0) {
status = SMC;
} else if (i == 1) {
@@ -4125,18 +4123,6 @@ de4x5_bad_srom(struct de4x5_private *lp)
return status;
}
-static int
-de4x5_strncmp(char *a, char *b, int n)
-{
- int ret=0;
-
- for (;n && !ret; n--) {
- ret = *a++ - *b++;
- }
-
- return ret;
-}
-
static void
srom_repair(struct net_device *dev, int card)
{
--
2.0.4
^ permalink raw reply related
* Re: Is this 32-bit NCM?y
From: Enrico Mioso @ 2014-12-04 10:33 UTC (permalink / raw)
To: Midge Shaojun Tan
Cc: Bjørn Mork, Kevin Zhu, Eli Britstein, Alex Strizhevsky,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <AMSPR06MB6011E001029C251790CB923EE780@AMSPR06MB601.eurprd06.prod.outlook.com>
... it works only applying cdc_ncm_modify.c; nothing else change. ARP works. Modesiwtch message not changed.
^ permalink raw reply
* [PATCH iproute2 v2] ss: Use rtnl_dump_filter in handle_netlink_request
From: Vadim Kochan @ 2014-12-04 10:32 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
Replaced handling netlink messages by rtnl_dump_filter
from lib/libnetlink.c, also:
- removed unused dump_fp arg;
- added MAGIC_SEQ #define for 123456 seq id;
- silently exit if ENOENT errno is caused for NETLINK_SOCK_DIAG proto
in lib/libnetlink.c: rtnl_duml_filter_l(...) function. This fix
was added in a3fd8e58c1787af186f5c4b234ff974544f840b6 by Eric
for misc/ss.c
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
include/libnetlink.h | 1 +
lib/libnetlink.c | 5 ++
misc/ss.c | 128 +++++++++++++++------------------------------------
3 files changed, 42 insertions(+), 92 deletions(-)
diff --git a/include/libnetlink.h b/include/libnetlink.h
index fe7d5d3..3794ef1 100644
--- a/include/libnetlink.h
+++ b/include/libnetlink.h
@@ -18,6 +18,7 @@ struct rtnl_handle
struct sockaddr_nl peer;
__u32 seq;
__u32 dump;
+ int proto;
};
extern int rcvbuf;
diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index 8d504a9..e3b7862 100644
--- a/lib/libnetlink.c
+++ b/lib/libnetlink.c
@@ -43,6 +43,7 @@ int rtnl_open_byproto(struct rtnl_handle *rth, unsigned subscriptions,
memset(rth, 0, sizeof(*rth));
+ rth->proto = protocol;
rth->fd = socket(AF_NETLINK, SOCK_RAW | SOCK_CLOEXEC, protocol);
if (rth->fd < 0) {
perror("Cannot open netlink socket");
@@ -245,6 +246,10 @@ int rtnl_dump_filter_l(struct rtnl_handle *rth,
"ERROR truncated\n");
} else {
errno = -err->error;
+ if (rth->proto == NETLINK_SOCK_DIAG &&
+ errno == ENOENT)
+ return -1;
+
perror("RTNETLINK answers");
}
return -1;
diff --git a/misc/ss.c b/misc/ss.c
index a99294d..68df122 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -41,6 +41,8 @@
#include <linux/packet_diag.h>
#include <linux/netlink_diag.h>
+#define MAGIC_SEQ 123456
+
#define DIAG_REQUEST(_req, _r) \
struct { \
struct nlmsghdr nlh; \
@@ -49,7 +51,7 @@
.nlh = { \
.nlmsg_type = SOCK_DIAG_BY_FAMILY, \
.nlmsg_flags = NLM_F_ROOT|NLM_F_MATCH|NLM_F_REQUEST,\
- .nlmsg_seq = 123456, \
+ .nlmsg_seq = MAGIC_SEQ, \
.nlmsg_len = sizeof(_req), \
}, \
}
@@ -1777,7 +1779,7 @@ static int tcpdiag_send(int fd, int protocol, struct filter *f)
req.nlh.nlmsg_type = DCCPDIAG_GETSOCK;
req.nlh.nlmsg_flags = NLM_F_ROOT|NLM_F_MATCH|NLM_F_REQUEST;
req.nlh.nlmsg_pid = 0;
- req.nlh.nlmsg_seq = 123456;
+ req.nlh.nlmsg_seq = MAGIC_SEQ;
memset(&req.r, 0, sizeof(req.r));
req.r.idiag_family = AF_INET;
req.r.idiag_states = f->states;
@@ -1937,7 +1939,7 @@ again:
struct inet_diag_msg *r = NLMSG_DATA(h);
if (/*h->nlmsg_pid != rth->local.nl_pid ||*/
- h->nlmsg_seq != 123456)
+ h->nlmsg_seq != MAGIC_SEQ)
goto skip_it;
if (h->nlmsg_type == NLMSG_DONE)
@@ -2422,8 +2424,10 @@ static void unix_list_print(struct unixstat *list, struct filter *f)
}
}
-static int unix_show_sock(struct nlmsghdr *nlh, struct filter *f)
+static int unix_show_sock(const struct sockaddr_nl *addr, struct nlmsghdr *nlh,
+ void *arg)
{
+ struct filter *f = (struct filter *)arg;
struct unix_diag_msg *r = NLMSG_DATA(nlh);
struct rtattr *tb[UNIX_DIAG_MAX+1];
char name[128];
@@ -2512,90 +2516,30 @@ static int unix_show_sock(struct nlmsghdr *nlh, struct filter *f)
return 0;
}
-static int handle_netlink_request(struct filter *f, FILE *dump_fp,
- struct nlmsghdr *req, size_t size,
- int (* show_one_sock)(struct nlmsghdr *nlh, struct filter *f))
+static int handle_netlink_request(struct filter *f, struct nlmsghdr *req,
+ size_t size, rtnl_filter_t show_one_sock)
{
- int fd;
- char buf[16384];
+ int ret = -1;
+ struct rtnl_handle rth;
- if ((fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_INET_DIAG)) < 0)
+ if (rtnl_open_byproto(&rth, 0, NETLINK_SOCK_DIAG))
return -1;
- if (send(fd, req, size, 0) < 0) {
- close(fd);
- return -1;
- }
+ rth.dump = MAGIC_SEQ;
- while (1) {
- ssize_t status;
- struct nlmsghdr *h;
- struct sockaddr_nl nladdr;
- socklen_t slen = sizeof(nladdr);
+ if (rtnl_send(&rth, req, size) < 0)
+ goto Exit;
- status = recvfrom(fd, buf, sizeof(buf), 0,
- (struct sockaddr *) &nladdr, &slen);
- if (status < 0) {
- if (errno == EINTR)
- continue;
- perror("OVERRUN");
- continue;
- }
- if (status == 0) {
- fprintf(stderr, "EOF on netlink\n");
- goto close_it;
- }
-
- if (dump_fp)
- fwrite(buf, 1, NLMSG_ALIGN(status), dump_fp);
-
- h = (struct nlmsghdr*)buf;
- while (NLMSG_OK(h, status)) {
- int err;
+ if (rtnl_dump_filter(&rth, show_one_sock, f))
+ goto Exit;
- if (/*h->nlmsg_pid != rth->local.nl_pid ||*/
- h->nlmsg_seq != 123456)
- goto skip_it;
-
- if (h->nlmsg_type == NLMSG_DONE)
- goto close_it;
-
- if (h->nlmsg_type == NLMSG_ERROR) {
- struct nlmsgerr *err = (struct nlmsgerr*)NLMSG_DATA(h);
- if (h->nlmsg_len < NLMSG_LENGTH(sizeof(struct nlmsgerr))) {
- fprintf(stderr, "ERROR truncated\n");
- } else {
- errno = -err->error;
- if (errno != ENOENT)
- fprintf(stderr, "DIAG answers %d\n", errno);
- }
- close(fd);
- return -1;
- }
- if (!dump_fp) {
- err = show_one_sock(h, f);
- if (err < 0) {
- close(fd);
- return err;
- }
- }
-
-skip_it:
- h = NLMSG_NEXT(h, status);
- }
-
- if (status) {
- fprintf(stderr, "!!!Remnant of size %zd\n", status);
- exit(1);
- }
- }
-
-close_it:
- close(fd);
- return 0;
+ ret = 0;
+Exit:
+ rtnl_close(&rth);
+ return ret;
}
-static int unix_show_netlink(struct filter *f, FILE *dump_fp)
+static int unix_show_netlink(struct filter *f)
{
DIAG_REQUEST(req, struct unix_diag_req r);
@@ -2605,8 +2549,7 @@ static int unix_show_netlink(struct filter *f, FILE *dump_fp)
if (show_mem)
req.r.udiag_show |= UDIAG_SHOW_MEMINFO;
- return handle_netlink_request(f, dump_fp, &req.nlh,
- sizeof(req), unix_show_sock);
+ return handle_netlink_request(f, &req.nlh, sizeof(req), unix_show_sock);
}
static int unix_show(struct filter *f)
@@ -2619,7 +2562,7 @@ static int unix_show(struct filter *f)
struct unixstat *list = NULL;
if (!getenv("PROC_NET_UNIX") && !getenv("PROC_ROOT")
- && unix_show_netlink(f, NULL) == 0)
+ && unix_show_netlink(f) == 0)
return 0;
if ((fp = net_unix_open()) == NULL)
@@ -2693,7 +2636,8 @@ static int unix_show(struct filter *f)
return 0;
}
-static int packet_show_sock(struct nlmsghdr *nlh, struct filter *f)
+static int packet_show_sock(const struct sockaddr_nl *addr,
+ struct nlmsghdr *nlh, void *arg)
{
struct packet_diag_msg *r = NLMSG_DATA(nlh);
struct rtattr *tb[PACKET_DIAG_MAX+1];
@@ -2786,15 +2730,14 @@ static int packet_show_sock(struct nlmsghdr *nlh, struct filter *f)
return 0;
}
-static int packet_show_netlink(struct filter *f, FILE *dump_fp)
+static int packet_show_netlink(struct filter *f)
{
DIAG_REQUEST(req, struct packet_diag_req r);
req.r.sdiag_family = AF_PACKET;
req.r.pdiag_show = PACKET_SHOW_INFO | PACKET_SHOW_MEMINFO | PACKET_SHOW_FILTER;
- return handle_netlink_request(f, dump_fp, &req.nlh, sizeof(req),
- packet_show_sock);
+ return handle_netlink_request(f, &req.nlh, sizeof(req), packet_show_sock);
}
@@ -2811,7 +2754,7 @@ static int packet_show(struct filter *f)
int ino;
unsigned long long sk;
- if (packet_show_netlink(f, NULL) == 0)
+ if (packet_show_netlink(f) == 0)
return 0;
if ((fp = net_packet_open()) == NULL)
@@ -2982,8 +2925,10 @@ static void netlink_show_one(struct filter *f,
return;
}
-static int netlink_show_sock(struct nlmsghdr *nlh, struct filter *f)
+static int netlink_show_sock(const struct sockaddr_nl *addr,
+ struct nlmsghdr *nlh, void *arg)
{
+ struct filter *f = (struct filter *)arg;
struct netlink_diag_msg *r = NLMSG_DATA(nlh);
struct rtattr *tb[NETLINK_DIAG_MAX+1];
int rq = 0, wq = 0;
@@ -3016,7 +2961,7 @@ static int netlink_show_sock(struct nlmsghdr *nlh, struct filter *f)
return 0;
}
-static int netlink_show_netlink(struct filter *f, FILE *dump_fp)
+static int netlink_show_netlink(struct filter *f)
{
DIAG_REQUEST(req, struct netlink_diag_req r);
@@ -3024,8 +2969,7 @@ static int netlink_show_netlink(struct filter *f, FILE *dump_fp)
req.r.sdiag_protocol = NDIAG_PROTO_ALL;
req.r.ndiag_show = NDIAG_SHOW_GROUPS | NDIAG_SHOW_MEMINFO;
- return handle_netlink_request(f, dump_fp, &req.nlh,
- sizeof(req), netlink_show_sock);
+ return handle_netlink_request(f, &req.nlh, sizeof(req), netlink_show_sock);
}
static int netlink_show(struct filter *f)
@@ -3038,7 +2982,7 @@ static int netlink_show(struct filter *f)
unsigned long long sk, cb;
if (!getenv("PROC_NET_NETLINK") && !getenv("PROC_ROOT") &&
- netlink_show_netlink(f, NULL) == 0)
+ netlink_show_netlink(f) == 0)
return 0;
if ((fp = net_netlink_open()) == NULL)
--
2.1.3
^ permalink raw reply related
* Re: [PATCH v3 net-next 2/2 tuntap: Increase the number of queues in tun.
From: Pankaj Gupta @ 2014-12-04 10:42 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jason Wang, linux-kernel, netdev, davem, dgibson, vfalico,
edumazet, vyasevic, hkchu, wuzhy, xemul, therbert, bhutchings,
xii, stephen, jiri, sergei shtylyov
In-Reply-To: <20141204102013.GC17122@redhat.com>
>
> On Thu, Dec 04, 2014 at 03:03:34AM +0008, Jason Wang wrote:
> >
> >
> > On Wed, Dec 3, 2014 at 5:52 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > >On Wed, Dec 03, 2014 at 12:49:37PM +0530, Pankaj Gupta wrote:
> > >> Networking under kvm works best if we allocate a per-vCPU RX and TX
> > >> queue in a virtual NIC. This requires a per-vCPU queue on the host
> > >>side.
> > >> It is now safe to increase the maximum number of queues.
> > >> Preceding patche: 'net: allow large number of rx queues'
> > >
> > >s/patche/patch/
> > >
> > >> made sure this won't cause failures due to high order memory
> > >> allocations. Increase it to 256: this is the max number of vCPUs
> > >> KVM supports.
> > >> Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
> > >> Reviewed-by: David Gibson <dgibson@redhat.com>
> > >
> > >Hmm it's kind of nasty that each tun device is now using x16 memory.
> > >Maybe we should look at using a flex array instead, and removing the
> > >limitation altogether (e.g. make it INT_MAX)?
> >
> > But this only happens when IFF_MULTIQUEUE were used.
>
> I refer to this field:
> struct tun_file __rcu *tfiles[MAX_TAP_QUEUES];
> if we make MAX_TAP_QUEUES 256, this will use 4K bytes,
> apparently unconditionally.
Are you saying use flow array for tfiles in-place of array of tun_file
pointer and grow dynamically when/if needed?
If yes, I agree it will be all order-1 allocation but it will add some level
of indirection as pointed by DaveM for flow, this time for tfiles. But yes, dynamically
allocating flex array as per usage will help to minimise memory pressure which in this
case is high, 256.
>
>
> > And core has vmalloc() fallback.
> > So probably not a big issue?
> > >
> > >
> > >
> > >> ---
> > >> drivers/net/tun.c | 9 +++++----
> > >> 1 file changed, 5 insertions(+), 4 deletions(-)
> > >> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > >> index e3fa65a..a19dc5f8 100644
> > >> --- a/drivers/net/tun.c
> > >> +++ b/drivers/net/tun.c
> > >> @@ -113,10 +113,11 @@ struct tap_filter {
> > >> unsigned char addr[FLT_EXACT_COUNT][ETH_ALEN];
> > >> };
> > >> -/* DEFAULT_MAX_NUM_RSS_QUEUES were chosen to let the rx/tx queues
> > >>allocated for
> > >> - * the netdevice to be fit in one page. So we can make sure the
> > >>success of
> > >> - * memory allocation. TODO: increase the limit. */
> > >> -#define MAX_TAP_QUEUES DEFAULT_MAX_NUM_RSS_QUEUES
> > >> +/* MAX_TAP_QUEUES 256 is chosen to allow rx/tx queues to be equal
> > >> + * to max number of vCPUS in guest. Also, we are making sure here
> > >> + * queue memory allocation do not fail.
> > >
> > >It's not queue memory allocation anymore, is it?
> > >I would say "
> > >This also helps the tfiles field fit in 4K, so the whole tun
> > >device only needs an order-1 allocation.
> > >"
> > >
> > >> + */
> > >> +#define MAX_TAP_QUEUES 256
> > >> #define MAX_TAP_FLOWS 4096
> > >> #define TUN_FLOW_EXPIRE (3 * HZ)
> > >> -- 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
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v3 net-next 1/2] net: allow large number of rx queues
From: Pankaj Gupta @ 2014-12-04 10:45 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, netdev, davem, jasowang, dgibson, vfalico, edumazet,
vyasevic, hkchu, wuzhy, xemul, therbert, bhutchings, xii, stephen,
jiri, sergei shtylyov
In-Reply-To: <20141203094224.GB9487@redhat.com>
>
> On Wed, Dec 03, 2014 at 12:49:36PM +0530, Pankaj Gupta wrote:
> > netif_alloc_rx_queues() uses kcalloc() to allocate memory
> > for "struct netdev_queue *_rx" array.
> > If we are doing large rx queue allocation kcalloc() might
> > fail, so this patch does a fallback to vzalloc().
> > Similar implementation is done for tx queue allocation in
> > netif_alloc_netdev_queues().
> >
> > We avoid failure of high order memory allocation
> > with the help of vzalloc(), this allows us to do large
> > rx and tx queue allocation which in turn helps us to
> > increase the number of queues in tun.
> >
> > As vmalloc() adds overhead on a critical network path,
> > __GFP_REPEAT flag is used with kzalloc() to do this fallback
> > only when really needed.
> >
> > Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
> > Reviewed-by: David Gibson <dgibson@redhat.com>
> > ---
> > net/core/dev.c | 19 +++++++++++++------
> > 1 file changed, 13 insertions(+), 6 deletions(-)
> >
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index e916ba8..abe9560 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -6059,17 +6059,25 @@ void netif_stacked_transfer_operstate(const struct
> > net_device *rootdev,
> > EXPORT_SYMBOL(netif_stacked_transfer_operstate);
> >
> > #ifdef CONFIG_SYSFS
> > +static void netif_free_rx_queues(struct net_device *dev)
> > +{
> > + kvfree(dev->_rx);
> > +}
> > +
>
> I would just open-code this.
I will make the changes with the next version.
Thanks,
Pankaj
>
> > static int netif_alloc_rx_queues(struct net_device *dev)
> > {
> > unsigned int i, count = dev->num_rx_queues;
> > struct netdev_rx_queue *rx;
> > + size_t sz = count * sizeof(*rx);
> >
> > BUG_ON(count < 1);
> >
> > - rx = kcalloc(count, sizeof(struct netdev_rx_queue), GFP_KERNEL);
> > - if (!rx)
> > - return -ENOMEM;
> > -
> > + rx = kzalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT);
> > + if (!rx) {
> > + rx = vzalloc(sz);
> > + if (!rx)
> > + return -ENOMEM;
> > + }
> > dev->_rx = rx;
> >
> > for (i = 0; i < count; i++)
> > @@ -6698,9 +6706,8 @@ void free_netdev(struct net_device *dev)
> >
> > netif_free_tx_queues(dev);
> > #ifdef CONFIG_SYSFS
> > - kfree(dev->_rx);
> > + netif_free_rx_queues(dev);
> > #endif
> > -
>
> and I think it's nicer with the empty line.
>
> > kfree(rcu_dereference_protected(dev->ingress_queue, 1));
> >
> > /* Flush device addresses */
> > --
> > 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
> --
> 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
* [PATCH net-next] bnx2x: Use correct fastpath version for VFs.
From: Yuval Mintz @ 2014-12-04 10:52 UTC (permalink / raw)
To: davem, netdev; +Cc: Ariel.Elior, Yuval Mintz
Our FW can support several fastpath HSI [for backward compatibility] but up
until now VFs were always configured to use latest fastpath HSI [although VF
driver might be older and use an older fastpath HSI].
For linux drivers, the differences are insignificant since driver never
utilized features that were overridden by the HSI change. But for VMs running
other operating systems this might be a problem.
In addition, eventually FW might change fastpath HSI in such a manner that
backward compatibility WILL break unless configured with proper version.
This patch fixes the issue for other operating system VMs, as well as lays
the ground work for forward compatibility in regard to the fastpath HSI.
Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: Ariel Elior <Ariel.Elior@qlogic.com>
---
Hi Dave,
Please consider applying this patch to `net-next'.
[Notice there's a single too-long line in it, but there was no 'good'
way of preventing it]
Thanks,
Yuval Mintz
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c | 2 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h | 2 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 1 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h | 2 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c | 75 ++++++++++++++++++++++-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.h | 9 ++-
7 files changed, 88 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 336ef3c..07c6368 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -3163,6 +3163,8 @@ static void bnx2x_pf_q_prep_general(struct bnx2x *bp,
gen_init->mtu = bp->dev->mtu;
gen_init->cos = cos;
+
+ gen_init->fp_hsi = ETH_FP_HSI_VERSION;
}
static void bnx2x_pf_rx_q_prep(struct bnx2x *bp,
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
index 7bc2924..07cdf9b 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
@@ -4336,7 +4336,7 @@ static void bnx2x_q_fill_init_general_data(struct bnx2x *bp,
test_bit(BNX2X_Q_FLG_FCOE, flags) ?
LLFC_TRAFFIC_TYPE_FCOE : LLFC_TRAFFIC_TYPE_NW;
- gen_data->fp_hsi_ver = ETH_FP_HSI_VERSION;
+ gen_data->fp_hsi_ver = params->fp_hsi;
DP(BNX2X_MSG_SP, "flags: active %d, cos %d, stats en %d\n",
gen_data->activate_flg, gen_data->cos, gen_data->statistics_en_flg);
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h
index e97275f..86baecb 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h
@@ -937,6 +937,8 @@ struct bnx2x_general_setup_params {
u8 spcl_id;
u16 mtu;
u8 cos;
+
+ u8 fp_hsi;
};
struct bnx2x_rxq_setup_params {
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
index c88b20a..e5aca2d 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
@@ -193,6 +193,7 @@ void bnx2x_vfop_qctor_prep(struct bnx2x *bp,
/* Setup-op general parameters */
setup_p->gen_params.spcl_id = vf->sp_cl_id;
setup_p->gen_params.stat_id = vfq_stat_id(vf, q);
+ setup_p->gen_params.fp_hsi = vf->fp_hsi;
/* Setup-op pause params:
* Nothing to do, the pause thresholds are set by default to 0 which
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h
index 01bafa4..66ee62a 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h
@@ -205,6 +205,8 @@ struct bnx2x_virtf {
/* slow-path operations */
struct mutex op_mutex; /* one vfop at a time mutex */
enum channel_tlvs op_current;
+
+ u8 fp_hsi;
};
#define BNX2X_NR_VIRTFN(bp) ((bp)->vfdb->sriov.nr_virtfn)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
index b1d9c44..be40eab 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
@@ -224,6 +224,7 @@ int bnx2x_vfpf_acquire(struct bnx2x *bp, u8 tx_count, u8 rx_count)
struct vfpf_acquire_tlv *req = &bp->vf2pf_mbox->req.acquire;
struct pfvf_acquire_resp_tlv *resp = &bp->vf2pf_mbox->resp.acquire_resp;
struct vfpf_port_phys_id_resp_tlv *phys_port_resp;
+ struct vfpf_fp_hsi_resp_tlv *fp_hsi_resp;
u32 vf_id;
bool resources_acquired = false;
@@ -237,6 +238,7 @@ int bnx2x_vfpf_acquire(struct bnx2x *bp, u8 tx_count, u8 rx_count)
req->vfdev_info.vf_id = vf_id;
req->vfdev_info.vf_os = 0;
+ req->vfdev_info.fp_hsi_ver = ETH_FP_HSI_VERSION;
req->resc_request.num_rxqs = rx_count;
req->resc_request.num_txqs = tx_count;
@@ -316,9 +318,14 @@ int bnx2x_vfpf_acquire(struct bnx2x *bp, u8 tx_count, u8 rx_count)
memset(&bp->vf2pf_mbox->resp, 0,
sizeof(union pfvf_tlvs));
} else {
- /* PF reports error */
- BNX2X_ERR("Failed to get the requested amount of resources: %d. Breaking...\n",
- bp->acquire_resp.hdr.status);
+ /* Determine reason of PF failure of acquire process */
+ fp_hsi_resp = bnx2x_search_tlv_list(bp, resp,
+ CHANNEL_TLV_FP_HSI_SUPPORT);
+ if (fp_hsi_resp && !fp_hsi_resp->is_supported)
+ BNX2X_ERR("Old hypervisor - doesn't support current fastpath HSI version; Need to downgrade VF driver [or upgrade hypervisor]\n");
+ else
+ BNX2X_ERR("Failed to get the requested amount of resources: %d. Breaking...\n",
+ bp->acquire_resp.hdr.status);
rc = -EAGAIN;
goto out;
}
@@ -333,6 +340,25 @@ int bnx2x_vfpf_acquire(struct bnx2x *bp, u8 tx_count, u8 rx_count)
bp->flags |= HAS_PHYS_PORT_ID;
}
+ /* Old Hypevisors might not even support the FP_HSI_SUPPORT TLV.
+ * If that's the case, we need to make certain required FW was
+ * supported by such a hypervisor [i.e., v0-v2].
+ */
+ fp_hsi_resp = bnx2x_search_tlv_list(bp, resp,
+ CHANNEL_TLV_FP_HSI_SUPPORT);
+ if (!fp_hsi_resp && (ETH_FP_HSI_VERSION > ETH_FP_HSI_VER_2)) {
+ BNX2X_ERR("Old hypervisor - need to downgrade VF's driver\n");
+
+ /* Since acquire succeeded on the PF side, we need to send a
+ * release message in order to allow future probes.
+ */
+ bnx2x_vfpf_finalize(bp, &req->first_tlv);
+ bnx2x_vfpf_release(bp);
+
+ rc = -EINVAL;
+ goto out;
+ }
+
/* get HW info */
bp->common.chip_id |= (bp->acquire_resp.pfdev_info.chip_num & 0xffff);
bp->link_params.chip_id = bp->common.chip_id;
@@ -1125,6 +1151,26 @@ static void bnx2x_vf_mbx_resp_phys_port(struct bnx2x *bp,
*offset += sizeof(struct vfpf_port_phys_id_resp_tlv);
}
+static void bnx2x_vf_mbx_resp_fp_hsi_ver(struct bnx2x *bp,
+ struct bnx2x_virtf *vf,
+ void *buffer,
+ u16 *offset)
+{
+ struct vfpf_fp_hsi_resp_tlv *fp_hsi;
+
+ bnx2x_add_tlv(bp, buffer, *offset, CHANNEL_TLV_FP_HSI_SUPPORT,
+ sizeof(struct vfpf_fp_hsi_resp_tlv));
+
+ fp_hsi = (struct vfpf_fp_hsi_resp_tlv *)
+ (((u8 *)buffer) + *offset);
+ fp_hsi->is_supported = (vf->fp_hsi > ETH_FP_HSI_VERSION) ? 0 : 1;
+
+ /* Offset should continue representing the offset to the tail
+ * of TLV data (outside this function scope)
+ */
+ *offset += sizeof(struct vfpf_fp_hsi_resp_tlv);
+}
+
static void bnx2x_vf_mbx_acquire_resp(struct bnx2x *bp, struct bnx2x_virtf *vf,
struct bnx2x_vf_mbx *mbx, int vfop_status)
{
@@ -1219,6 +1265,12 @@ static void bnx2x_vf_mbx_acquire_resp(struct bnx2x *bp, struct bnx2x_virtf *vf,
CHANNEL_TLV_PHYS_PORT_ID))
bnx2x_vf_mbx_resp_phys_port(bp, vf, &mbx->msg->resp, &length);
+ /* `New' vfs will want to know if fastpath HSI is supported, since
+ * if that's not the case they could print into system log the fact
+ * the driver version must be updated.
+ */
+ bnx2x_vf_mbx_resp_fp_hsi_ver(bp, vf, &mbx->msg->resp, &length);
+
bnx2x_add_tlv(bp, &mbx->msg->resp, length, CHANNEL_TLV_LIST_END,
sizeof(struct channel_list_end_tlv));
@@ -1288,6 +1340,23 @@ static void bnx2x_vf_mbx_acquire(struct bnx2x *bp, struct bnx2x_virtf *vf,
goto out;
}
+ /* Verify the VF fastpath HSI can be supported by the loaded FW.
+ * Linux vfs should be oblivious to changes between v0 and v2.
+ */
+ if (bnx2x_vf_mbx_is_windows_vm(bp, &mbx->msg->req.acquire))
+ vf->fp_hsi = acquire->vfdev_info.fp_hsi_ver;
+ else
+ vf->fp_hsi = max_t(u8, acquire->vfdev_info.fp_hsi_ver,
+ ETH_FP_HSI_VER_2);
+ if (vf->fp_hsi > ETH_FP_HSI_VERSION) {
+ DP(BNX2X_MSG_IOV,
+ "VF [%d] - Can't support acquire request since VF requests a FW version which is too new [%02x > %02x]\n",
+ vf->abs_vfid, acquire->vfdev_info.fp_hsi_ver,
+ ETH_FP_HSI_VERSION);
+ rc = -EINVAL;
+ goto out;
+ }
+
/* acquire the resources */
rc = bnx2x_vf_acquire(bp, vf, &acquire->resc_request);
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.h
index 15670c4..b86479f 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.h
@@ -124,7 +124,7 @@ struct vfpf_acquire_tlv {
#define VF_OS_UNDEFINED (0 << VF_OS_SHIFT)
#define VF_OS_WINDOWS (1 << VF_OS_SHIFT)
- u8 padding;
+ u8 fp_hsi_ver;
u8 caps;
#define VF_CAP_SUPPORT_EXT_BULLETIN (1 << 0)
} vfdev_info;
@@ -204,6 +204,12 @@ struct vfpf_port_phys_id_resp_tlv {
u8 padding[2];
};
+struct vfpf_fp_hsi_resp_tlv {
+ struct channel_tlv tl;
+ u8 is_supported;
+ u8 padding[3];
+};
+
#define VFPF_INIT_FLG_STATS_COALESCE (1 << 0) /* when set the VFs queues
* stats will be coalesced on
* the leading RSS queue
@@ -448,6 +454,7 @@ enum channel_tlvs {
CHANNEL_TLV_UPDATE_RSS,
CHANNEL_TLV_PHYS_PORT_ID,
CHANNEL_TLV_UPDATE_TPA,
+ CHANNEL_TLV_FP_HSI_SUPPORT,
CHANNEL_TLV_MAX
};
--
1.9.3
^ permalink raw reply related
* Re: [PATCH] SSB / B44: fix WOL for BCM4401
From: Andrey Skvortsov @ 2014-12-04 11:11 UTC (permalink / raw)
To: Michael Büsch
Cc: John W. Linville, Larry Finger, Rafael J. Wysocki, Gary.Zambrano,
netdev, linux-kernel, b43-dev, Rafał Miłecki
In-Reply-To: <20141203172315.120040c2@wiggum>
[-- Attachment #1: Type: text/plain, Size: 820 bytes --]
On Wed, Dec 03, 2014 at 05:23:15PM +0100, Michael Büsch wrote:
> > > > > That sounds good, indeed.
> > > > > I'd still prefer, if someone with b43 (wireless) would test it, too.
> > > >
> > > > I did a partial test with my PowerBook G4. With the patch installed, it would
> > > > both suspend and hibernate, but WOL would be impossible. This computer uses a
> > > > PCMCIA version of the BCM4318, and power is turned off to the PCMCIA card when
> > > > suspended or hibernating.
> > >
> > > Thanks for testing.
> > >
> > > John, can you take this one? Or do we need to split the b44 part out?
> > > I added my Signed-off.
> >
> > Um, sure...3.19 is OK I presume?
>
> I think we could even wait for 3.20.
>
Thanks, guys.
--
Best regards,
Andrey Skvortsov
PGP Key ID: 0x57A3AEAD
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Bjørn Mork @ 2014-12-04 11:44 UTC (permalink / raw)
To: Midge Shaojun Tan
Cc: Enrico Mioso, Kevin Zhu, Eli Britstein, Alex Strizhevsky,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <AMSPR06MB6011E001029C251790CB923EE780@AMSPR06MB601.eurprd06.prod.outlook.com>
"Midge Shaojun Tan" <ShaojunMidge.Tan@audiocodes.com> writes:
> Hi all,
>
> I test OK with kervel 3.16.4
> Need disable other Ethernet network, just like eth1. (Then the DNS and route is OK)
> And also need disable arp, (ifconfig wwan0 -arp up), because China UNICOM don't respond the ARP message.
The ARP functionality is independent of operator. It is handled
internally by the modem firmware. There are no MAC addresses or
ethernet headers transmitted over the radio link. That's all faked by
the modem. All MAC addresses and ethernet headers are local to the
modem<->host USB link.
> With new mode switch string: /etc/usb_modeswitch.d/12d1:14fe
> Please see the patch and check whether it is correct?
I see that you have two changes there:
1) the ETH_HLEN adjustment of ctx->tx_remainder is dropped
2) the NDP is placed after the first frame.
I haven't verified the effect of the tx_remainder change, but I assume
it fixes an alignment problem for this device. I'd like to look more at
the effect of this for different values of wNdpOutPayloadRemainder and
wNdpOutDivisor.
We can choose to put the NDP at the end of the NTB if we find that this
fixes some problem, but doing so by default for every NCM and MBIM
device is a bit risky. If we accept that some devices are so buggy that
the NDP cannot be placed anywhere (as required by the spec), then we
have to assume that this goes both ways. Which means that moving the
NDP to the end of the NTB might break some other device. We just don't
know that since we haven't ever tried it.
And your fix doesn't really move it to the end either. It just places
the NDP after the first ethernet packet. Which happens to be the end if
there is only one packet in the NTB. But if we aggregate more packets
into this NTB then the result will look like this:
NTH
eth packet 1
NDP
eth packet 2
..
eth packet N
I'm not convinced this modem will handle that if it cannot handle the
NDP being before the first packet... This needs to be tested. Try
increasing /sys/class/net/wwan0/cdc_ncm/tx_timer_usecs to force the
driver to aggregate packets and see if everything still works.
Preferably while looking at the resulting NTB to verify that it does
contain more than one ethernet packet.
I realize I sound a bit negative now. This is absolutely not my
intention. This is great work, providing some real progress wrt figuring
out what goes on here. Thanks a lot! I am sure we can sort out the
remaining issues, which are really minor compared to what you have found
so far.
Bjørn
^ permalink raw reply
* Possible regression: "gre: Use inner mac length when computing tunnel length"
From: Timo Teras @ 2014-12-04 12:16 UTC (permalink / raw)
To: Tom Herbert, Alexander Duyck, netdev
Hi,
After upgrading to latest 3.14.24 or newer, I noticed a weird TSO bug
in the "dmvpn" setup I use. And seems 3.14.23 works just fine. So the
commit 14051f0452a2c26a "gre: Use inner mac length when computing
tunnel length" would appear to be the related commit (but have not yet
tested this).
In practice what happens is that forwarding path between ethX (or vlanX)
and gre1 gets broken.
There's probably two differences to the "regular" gre tunnel case:
- it's nbma mode, meaning the gre header is inserted via slightly
different code path
- the gre1 packets are IPsec encrypted in transport mode
As additional detail, doing "ethtool -K gre1 tso off" will workaround
the issue, so it is clearly tso issue pointing even further to the
commit in question.
Is this something the suspected patch could cause? Any suggestions
what to test more?
Thanks,
Timo
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Enrico Mioso @ 2014-12-04 12:17 UTC (permalink / raw)
To: Bjørn Mork
Cc: Midge Shaojun Tan, Kevin Zhu, Eli Britstein, Alex Strizhevsky,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <877fy7myfb.fsf@nemi.mork.no>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3995 bytes --]
On Thu, 4 Dec 2014, Bjørn Mork wrote:
> "Midge Shaojun Tan" <ShaojunMidge.Tan@audiocodes.com> writes:
>
>> Hi all,
>>
>> I test OK with kervel 3.16.4
>> Need disable other Ethernet network, just like eth1. (Then the DNS and route is OK)
>> And also need disable arp, (ifconfig wwan0 -arp up), because China UNICOM don't respond the ARP message.
>
> The ARP functionality is independent of operator. It is handled
> internally by the modem firmware. There are no MAC addresses or
> ethernet headers transmitted over the radio link. That's all faked by
> the modem. All MAC addresses and ethernet headers are local to the
> modem<->host USB link.
>
>> With new mode switch string: /etc/usb_modeswitch.d/12d1:14fe
>> Please see the patch and check whether it is correct?
>
> I see that you have two changes there:
>
> 1) the ETH_HLEN adjustment of ctx->tx_remainder is dropped
> 2) the NDP is placed after the first frame.
>
> I haven't verified the effect of the tx_remainder change, but I assume
> it fixes an alignment problem for this device. I'd like to look more at
> the effect of this for different values of wNdpOutPayloadRemainder and
> wNdpOutDivisor.
>
> We can choose to put the NDP at the end of the NTB if we find that this
> fixes some problem, but doing so by default for every NCM and MBIM
> device is a bit risky. If we accept that some devices are so buggy that
> the NDP cannot be placed anywhere (as required by the spec), then we
> have to assume that this goes both ways. Which means that moving the
> NDP to the end of the NTB might break some other device. We just don't
> know that since we haven't ever tried it.
Guys - this is a little hard moment for my life, so sorry if I sound negative
too, really. No humor here.
Bjorn, I am starting to think that we might need to (sadly) differentiate how
we threat "standard" NCM devices in respect to Huawei ones, a little bit more.
As you said - changing the handling in any way would be too risky - and
definitely, I am starting to think that different firmware versions have
different bugs in this regard (might be not in NCM handling itself, but in
respect to other areas, like ARP handling / faking ).
At the end we might come out with a good enough solution - but we would start
to complicate things more and more, and definitely we might end up complicating
more and more the driver itself. At some point, we might also end up finding
out that we need a different workarounds for different firmwares, not even
compatible one another.
so - my idea, that is hypotetical:
1 - Factorize out cdc_ncm more
2 - Creating new {tx,rx}_fixup routines applying different workarounds.
then, when the need to apply different workarounds for difference device (or
firmware versions) arise, we might also think of a way to communicate to the
driver the firmware version, allowing it to select some quirks to apply.
What do you all think about it?
> And your fix doesn't really move it to the end either. It just places
> the NDP after the first ethernet packet. Which happens to be the end if
> there is only one packet in the NTB. But if we aggregate more packets
> into this NTB then the result will look like this:
>
> NTH
> eth packet 1
> NDP
> eth packet 2
> ..
> eth packet N
>
> I'm not convinced this modem will handle that if it cannot handle the
> NDP being before the first packet... This needs to be tested. Try
> increasing /sys/class/net/wwan0/cdc_ncm/tx_timer_usecs to force the
> driver to aggregate packets and see if everything still works.
> Preferably while looking at the resulting NTB to verify that it does
> contain more than one ethernet packet.
>
> I realize I sound a bit negative now. This is absolutely not my
> intention. This is great work, providing some real progress wrt figuring
> out what goes on here. Thanks a lot! I am sure we can sort out the
> remaining issues, which are really minor compared to what you have found
> so far.
>
>
>
> Bjørn
>
>
I'll test this now.
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Enrico Mioso @ 2014-12-04 12:28 UTC (permalink / raw)
To: Bjørn Mork
Cc: Midge Shaojun Tan, Kevin Zhu, Eli Britstein, Alex Strizhevsky,
youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <877fy7myfb.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3917 bytes --]
... DHCP will work with some DHCPNACKS in the meanwhile, but ping stops working at all.
Otherwise, it works with the standard value:
--- 8.8.8.8 ping statistics ---
48 packets transmitted, 48 received, 0% packet loss, time 47004ms
rtt min/avg/max/mdev = 362.084/392.878/523.132/33.636 ms
And I was expecting effectively to see some lost packets, but instead... no.
On Thu, 4 Dec 2014, Bjørn Mork wrote:
> Date: Thu, 4 Dec 2014 12:44:56
> From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> To: Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
> Cc: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
> Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
> Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
> Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
> "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
> "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
> "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Subject: Re: Is this 32-bit NCM?y
>
> "Midge Shaojun Tan" <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> writes:
>
>> Hi all,
>>
>> I test OK with kervel 3.16.4
>> Need disable other Ethernet network, just like eth1. (Then the DNS and route is OK)
>> And also need disable arp, (ifconfig wwan0 -arp up), because China UNICOM don't respond the ARP message.
>
> The ARP functionality is independent of operator. It is handled
> internally by the modem firmware. There are no MAC addresses or
> ethernet headers transmitted over the radio link. That's all faked by
> the modem. All MAC addresses and ethernet headers are local to the
> modem<->host USB link.
>
>> With new mode switch string: /etc/usb_modeswitch.d/12d1:14fe
>> Please see the patch and check whether it is correct?
>
> I see that you have two changes there:
>
> 1) the ETH_HLEN adjustment of ctx->tx_remainder is dropped
> 2) the NDP is placed after the first frame.
>
> I haven't verified the effect of the tx_remainder change, but I assume
> it fixes an alignment problem for this device. I'd like to look more at
> the effect of this for different values of wNdpOutPayloadRemainder and
> wNdpOutDivisor.
>
> We can choose to put the NDP at the end of the NTB if we find that this
> fixes some problem, but doing so by default for every NCM and MBIM
> device is a bit risky. If we accept that some devices are so buggy that
> the NDP cannot be placed anywhere (as required by the spec), then we
> have to assume that this goes both ways. Which means that moving the
> NDP to the end of the NTB might break some other device. We just don't
> know that since we haven't ever tried it.
>
> And your fix doesn't really move it to the end either. It just places
> the NDP after the first ethernet packet. Which happens to be the end if
> there is only one packet in the NTB. But if we aggregate more packets
> into this NTB then the result will look like this:
>
> NTH
> eth packet 1
> NDP
> eth packet 2
> ..
> eth packet N
>
> I'm not convinced this modem will handle that if it cannot handle the
> NDP being before the first packet... This needs to be tested. Try
> increasing /sys/class/net/wwan0/cdc_ncm/tx_timer_usecs to force the
> driver to aggregate packets and see if everything still works.
> Preferably while looking at the resulting NTB to verify that it does
> contain more than one ethernet packet.
>
> I realize I sound a bit negative now. This is absolutely not my
> intention. This is great work, providing some real progress wrt figuring
> out what goes on here. Thanks a lot! I am sure we can sort out the
> remaining issues, which are really minor compared to what you have found
> so far.
>
>
>
> Bjørn
>
>
^ permalink raw reply
* Re: Where exactly will arch_fast_hash be used
From: Hannes Frederic Sowa @ 2014-12-04 12:34 UTC (permalink / raw)
To: Herbert Xu
Cc: Thomas Graf, Daniel Borkmann, David S. Miller, Theodore Ts'o,
netdev, Linux Kernel Mailing List
In-Reply-To: <20141204081147.GA19030@gondor.apana.org.au>
Hi Herbert,
On Do, 2014-12-04 at 16:11 +0800, Herbert Xu wrote:
> While working on rhashtable it came to me that this whole concept
> of arch_fast_hash is flawed. CRCs are linear functions so it's
> fairly easy for an attacker to identify collisions or at least
> eliminate a large amount of search space (e.g., controlling the
> last bit of the hash result is almost trivial, even when you add
> a random seed).
>
> So what exactly are we going to use arch_fast_hash for? Presumably
> it's places where security is never goint to be an issue, right?
>
> Even if security wasn't an issue, straight CRC32 has really poor
> lower-order bit distribution, which makes it a terrible choice for
> a hash table that simply uses the lower-order bits.
I wondered the same while trying to use arch_fast_hash in a lot more
places (I did a new implementation in assembler I'll send later on, it
is mostly optimized to deal with ovs flow keys).
While the uniformity of crc32 does actually look good and IMHO this even
holds for the lower bits of the hash, I totally agree on the linearity
matters.
The easiest way to make arch_fast_hash non-linear would be to build up
on the crc32 instruction like e.g. the cityhash function family does and
it seems not too hard to do that by combining two crc32c outputs of the
original and cyclic shifted input data. I have doubts if this is faster
than jhash in the end. There are proposals from Intel to do so, but they
are patent encumbered. :/
For most consumers in the networking stack, security and DoS resistence
is an issue. OVS, for which this was designed at first does do rehashing
from time to time, but still there is a possible DoS attack vector with
this hashing algorithm.
Bye,
Hannes
^ permalink raw reply
* [PATCH net-next] arch_fast_hash: avoid indirect function calls and implement hash in asm
From: Hannes Frederic Sowa @ 2014-12-04 13:08 UTC (permalink / raw)
To: netdev; +Cc: Herbert Xu, Jay Vosburgh, Thomas Graf, Daniel Borkmann,
Eric Dumazet
By default the arch_fast_hash hashing function pointers are initialized
to jhash(2). If during boot-up a CPU with SSE4.2 is detected they get
updated to the CRC32 ones. This dispatching scheme incurs a function
pointer lookup and indirect call for every hashing operation.
To keep the number of clobbered registers short the hashing primitives
are implemented in assembler. This makes it easier to do the dispatch
by alternative_call.
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Jay Vosburgh <jay.vosburgh@canonical.com>
Cc: Thomas Graf <tgraf@suug.ch>
Cc: Daniel Borkmann <dborkman@redhat.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
arch/x86/include/asm/hash.h | 53 ++++++++++-
arch/x86/kernel/i386_ksyms_32.c | 6 ++
arch/x86/kernel/x8664_ksyms_64.c | 6 ++
arch/x86/lib/Makefile | 2 +-
arch/x86/lib/arch_hash.S | 192 +++++++++++++++++++++++++++++++++++++++
arch/x86/lib/hash.c | 92 -------------------
arch/x86/lib/jhash.c | 6 ++
include/asm-generic/hash.h | 18 +++-
include/linux/hash.h | 34 -------
lib/Makefile | 2 +-
lib/hash.c | 39 --------
net/openvswitch/flow_table.c | 2 +-
12 files changed, 280 insertions(+), 172 deletions(-)
create mode 100644 arch/x86/lib/arch_hash.S
delete mode 100644 arch/x86/lib/hash.c
create mode 100644 arch/x86/lib/jhash.c
delete mode 100644 lib/hash.c
diff --git a/arch/x86/include/asm/hash.h b/arch/x86/include/asm/hash.h
index e8c58f8..620081b 100644
--- a/arch/x86/include/asm/hash.h
+++ b/arch/x86/include/asm/hash.h
@@ -1,7 +1,56 @@
#ifndef _ASM_X86_HASH_H
#define _ASM_X86_HASH_H
-struct fast_hash_ops;
-extern void setup_arch_fast_hash(struct fast_hash_ops *ops);
+#include <linux/cpufeature.h>
+#include <asm/alternative.h>
+
+#include <linux/jhash.h>
+
+#ifdef CONFIG_AS_CRC32
+
+u32 __jhash_trampoline(const void *data, u32 len, u32 seed);
+u32 __sse42_crc32(const void *data, u32 len, u32 seed);
+
+#ifdef CONFIG_X86_64
+
+static inline u32 arch_fast_hash(const void *data, u32 len, u32 seed)
+{
+ u32 hash;
+
+ alternative_call(__jhash_trampoline, __sse42_crc32, X86_FEATURE_XMM4_2,
+ ASM_OUTPUT2("=a" (hash), "=D" (data), "=S" (len),
+ "=d" (seed)),
+ "1" (data), "2" (len), "3" (seed)
+ : "memory", "cc");
+
+ return hash;
+}
+
+#else /* CONFIG_X86_64 */
+
+static inline u32 arch_fast_hash(const void *data, u32 len, u32 seed)
+{
+ u32 hash;
+
+ alternative_call(__jhash_trampoline, __sse42_crc32, X86_FEATURE_XMM4_2,
+ ASM_OUTPUT2("=a" (hash), "=d" (len), "=c" (seed)),
+ "0" (data), "1" (len), "2" (seed)
+ : "memory", "cc");
+
+ return hash;
+}
+
+#endif /* CONFIG_x86_64 */
+
+#else /* CONFIG_AS_CRC32 */
+
+u32 __jhash(const void *data, u32 len, u32 seed);
+
+static inline u32 arch_fast_hash(const void *data, u32 len, u32 seed)
+{
+ return __jhash(data, len, seed);
+}
+
+#endif
#endif /* _ASM_X86_HASH_H */
diff --git a/arch/x86/kernel/i386_ksyms_32.c b/arch/x86/kernel/i386_ksyms_32.c
index 05fd74f..afb98da 100644
--- a/arch/x86/kernel/i386_ksyms_32.c
+++ b/arch/x86/kernel/i386_ksyms_32.c
@@ -1,4 +1,5 @@
#include <linux/module.h>
+#include <linux/hash.h>
#include <asm/checksum.h>
#include <asm/pgtable.h>
@@ -38,6 +39,11 @@ EXPORT_SYMBOL(strstr);
EXPORT_SYMBOL(csum_partial);
EXPORT_SYMBOL(empty_zero_page);
+#ifdef CONFIG_AS_CRC32
+EXPORT_SYMBOL(__sse42_crc32);
+EXPORT_SYMBOL(__jhash_trampoline);
+#endif
+
#ifdef CONFIG_PREEMPT
EXPORT_SYMBOL(___preempt_schedule);
#ifdef CONFIG_CONTEXT_TRACKING
diff --git a/arch/x86/kernel/x8664_ksyms_64.c b/arch/x86/kernel/x8664_ksyms_64.c
index 0406819..1094c13 100644
--- a/arch/x86/kernel/x8664_ksyms_64.c
+++ b/arch/x86/kernel/x8664_ksyms_64.c
@@ -3,6 +3,7 @@
#include <linux/module.h>
#include <linux/smp.h>
+#include <linux/hash.h>
#include <net/checksum.h>
@@ -42,6 +43,11 @@ EXPORT_SYMBOL(clear_page);
EXPORT_SYMBOL(csum_partial);
+#ifdef CONFIG_AS_CRC32
+EXPORT_SYMBOL(__sse42_crc32);
+EXPORT_SYMBOL(__jhash_trampoline);
+#endif
+
/*
* Export string functions. We normally rely on gcc builtin for most of these,
* but gcc sometimes decides not to inline them.
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index db92793..168bbef 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -23,7 +23,7 @@ lib-y += memcpy_$(BITS).o
lib-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o
lib-$(CONFIG_INSTRUCTION_DECODER) += insn.o inat.o
-obj-y += msr.o msr-reg.o msr-reg-export.o hash.o
+obj-y += msr.o msr-reg.o msr-reg-export.o jhash.o arch_hash.o
ifeq ($(CONFIG_X86_32),y)
obj-y += atomic64_32.o
diff --git a/arch/x86/lib/arch_hash.S b/arch/x86/lib/arch_hash.S
new file mode 100644
index 0000000..ff526a4
--- /dev/null
+++ b/arch/x86/lib/arch_hash.S
@@ -0,0 +1,192 @@
+#include <linux/linkage.h>
+#include <asm/dwarf2.h>
+#include <asm/calling.h>
+
+#ifdef CONFIG_AS_CRC32
+
+#ifdef CONFIG_X86_64
+
+ENTRY(__jhash_trampoline)
+ CFI_STARTPROC
+
+ pushq_cfi %rcx
+ pushq_cfi %r8
+ pushq_cfi %r9
+ pushq_cfi %r10
+ pushq_cfi %r11
+
+ call __jhash
+
+ popq_cfi %r11
+ popq_cfi %r10
+ popq_cfi %r9
+ popq_cfi %r8
+ popq_cfi %rcx
+
+ retq
+
+ CFI_ENDPROC
+ENDPROC(__jhash_trampoline)
+
+ENTRY(__sse42_crc32)
+ CFI_STARTPROC
+
+ movq %rdx, %rax
+ cmpq $0x40, %rsi
+ jb .Lcrc_32bytes
+ subq $0x40, %rsi
+
+.Lcrc_64bytes:
+ subq $0x40, %rsi
+ crc32q 0*8(%rdi), %rax
+ crc32q 1*8(%rdi), %rax
+ crc32q 2*8(%rdi), %rax
+ crc32q 3*8(%rdi), %rax
+ crc32q 4*8(%rdi), %rax
+ crc32q 5*8(%rdi), %rax
+ crc32q 6*8(%rdi), %rax
+ crc32q 7*8(%rdi), %rax
+ leaq 8*8(%rdi), %rdi
+ jae .Lcrc_64bytes
+ addq $0x40, %rsi
+
+.Lcrc_32bytes:
+ cmpq $0x20, %rsi
+ jb .Lcrc_16bytes
+
+ subq $0x20, %rsi
+ crc32q 0*8(%rdi), %rax
+ crc32q 1*8(%rdi), %rax
+ crc32q 2*8(%rdi), %rax
+ crc32q 3*8(%rdi), %rax
+ leaq 4*8(%rdi), %rdi
+
+.Lcrc_16bytes:
+ cmpq $0x10, %rsi
+ jb .Lcrc_8bytes
+
+ subq $0x10, %rsi
+ crc32q 0*8(%rdi), %rax
+ crc32q 1*8(%rdi), %rax
+ leaq 2*8(%rdi), %rdi
+
+.Lcrc_8bytes:
+ cmpq $0x8, %rsi
+ jb .Lcrc_4bytes
+
+ subq $0x8, %rsi
+ crc32q (%rdi), %rax
+ leaq 1*8(%rdi), %rdi
+
+.Lcrc_4bytes:
+ cmpq $0x4, %rsi
+ jb .Lcrc_2bytes
+
+ subq $0x4, %rsi
+ crc32l (%rdi), %eax
+ leaq 1*4(%rdi), %rdi
+
+.Lcrc_2bytes:
+ cmpq $0x2, %rsi
+ jb .Lcrc_1bytes
+
+ subq $0x2, %rsi
+ crc32w (%rdi), %eax
+ leaq 1*2(%rdi), %rdi
+
+.Lcrc_1bytes:
+ cmpq $0x1, %rsi
+ jb .Lend
+
+ crc32b (%rdi), %eax
+.Lend:
+ retq
+ CFI_ENDPROC
+ENDPROC(__sse42_crc32)
+
+#else /* CONFIG_X86_32 */
+
+ENTRY(__jhash_trampoline)
+ CFI_STARTPROC
+
+ call __jhash
+
+ retl
+ CFI_ENDPROC
+ENDPROC(__jhash_trampoline)
+
+ENTRY(__sse42_crc32)
+ CFI_STARTPROC
+
+ xchgl %eax,%ecx
+ xchgl %edx,%ecx
+
+ cmpl $0x20, %ecx
+ jb .Lcrc_16bytes
+ subl $0x20, %ecx
+
+.Lcrc_32bytes:
+ subl $0x20, %ecx
+ crc32l 0*4(%edx), %eax
+ crc32l 1*4(%edx), %eax
+ crc32l 2*4(%edx), %eax
+ crc32l 3*4(%edx), %eax
+ crc32l 4*4(%edx), %eax
+ crc32l 5*4(%edx), %eax
+ crc32l 6*4(%edx), %eax
+ crc32l 7*4(%edx), %eax
+ leal 8*4(%edx), %edx
+ jae .Lcrc_32bytes
+ addl $0x20, %ecx
+
+.Lcrc_16bytes:
+ cmpl $0x10, %ecx
+ jb .Lcrc_8bytes
+
+ subl $0x10, %ecx
+ crc32l 0*4(%edx), %eax
+ crc32l 1*4(%edx), %eax
+ crc32l 2*4(%edx), %eax
+ crc32l 3*4(%edx), %eax
+ leal 4*4(%edx), %edx
+
+.Lcrc_8bytes:
+ cmpl $0x8, %ecx
+ jb .Lcrc_4bytes
+
+ subl $0x8, %ecx
+ crc32l 0*4(%edx), %eax
+ crc32l 1*4(%edx), %eax
+ leal 2*4(%edx), %edx
+
+.Lcrc_4bytes:
+ cmpl $0x4, %ecx
+ jb .Lcrc_2bytes
+
+ subl $0x4, %ecx
+ crc32l 0*4(%edx), %eax
+ leal 1*4(%edx), %edx
+
+.Lcrc_2bytes:
+ cmpl $0x2, %ecx
+ jb .Lcrc_1bytes
+
+ subl $0x2, %ecx
+ crc32w (%edx), %eax
+ leal 1*2(%edx), %edx
+
+.Lcrc_1bytes:
+ cmpl $0x1, %ecx
+ jb .Lend
+
+ crc32b (%edx), %eax
+
+.Lend:
+ retl
+
+ CFI_ENDPROC
+ENDPROC(__sse42_crc32)
+
+#endif
+
+#endif /* CONFIG_AS_CRC32 */
diff --git a/arch/x86/lib/hash.c b/arch/x86/lib/hash.c
deleted file mode 100644
index ff4fa51..0000000
--- a/arch/x86/lib/hash.c
+++ /dev/null
@@ -1,92 +0,0 @@
-/*
- * Some portions derived from code covered by the following notice:
- *
- * Copyright (c) 2010-2013 Intel Corporation. All rights reserved.
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * * Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- * * Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in
- * the documentation and/or other materials provided with the
- * distribution.
- * * Neither the name of Intel Corporation nor the names of its
- * contributors may be used to endorse or promote products derived
- * from this software without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-#include <linux/hash.h>
-#include <linux/init.h>
-
-#include <asm/processor.h>
-#include <asm/cpufeature.h>
-#include <asm/hash.h>
-
-static inline u32 crc32_u32(u32 crc, u32 val)
-{
-#ifdef CONFIG_AS_CRC32
- asm ("crc32l %1,%0\n" : "+r" (crc) : "rm" (val));
-#else
- asm (".byte 0xf2, 0x0f, 0x38, 0xf1, 0xc1" : "+a" (crc) : "c" (val));
-#endif
- return crc;
-}
-
-static u32 intel_crc4_2_hash(const void *data, u32 len, u32 seed)
-{
- const u32 *p32 = (const u32 *) data;
- u32 i, tmp = 0;
-
- for (i = 0; i < len / 4; i++)
- seed = crc32_u32(seed, *p32++);
-
- switch (len & 3) {
- case 3:
- tmp |= *((const u8 *) p32 + 2) << 16;
- /* fallthrough */
- case 2:
- tmp |= *((const u8 *) p32 + 1) << 8;
- /* fallthrough */
- case 1:
- tmp |= *((const u8 *) p32);
- seed = crc32_u32(seed, tmp);
- break;
- }
-
- return seed;
-}
-
-static u32 intel_crc4_2_hash2(const u32 *data, u32 len, u32 seed)
-{
- const u32 *p32 = (const u32 *) data;
- u32 i;
-
- for (i = 0; i < len; i++)
- seed = crc32_u32(seed, *p32++);
-
- return seed;
-}
-
-void __init setup_arch_fast_hash(struct fast_hash_ops *ops)
-{
- if (cpu_has_xmm4_2) {
- ops->hash = intel_crc4_2_hash;
- ops->hash2 = intel_crc4_2_hash2;
- }
-}
diff --git a/arch/x86/lib/jhash.c b/arch/x86/lib/jhash.c
new file mode 100644
index 0000000..ab4b408
--- /dev/null
+++ b/arch/x86/lib/jhash.c
@@ -0,0 +1,6 @@
+#include <linux/jhash.h>
+
+u32 __jhash(const void *data, u32 len, u32 seed)
+{
+ return jhash(data, len, seed);
+}
diff --git a/include/asm-generic/hash.h b/include/asm-generic/hash.h
index b631284..07b8892 100644
--- a/include/asm-generic/hash.h
+++ b/include/asm-generic/hash.h
@@ -1,9 +1,23 @@
#ifndef __ASM_GENERIC_HASH_H
#define __ASM_GENERIC_HASH_H
-struct fast_hash_ops;
-static inline void setup_arch_fast_hash(struct fast_hash_ops *ops)
+#include <linux/jhash.h>
+
+/**
+ * arch_fast_hash - Caclulates a hash over a given buffer that can have
+ * arbitrary size. This function will eventually use an
+ * architecture-optimized hashing implementation if
+ * available, and trades off distribution for speed.
+ *
+ * @data: buffer to hash
+ * @len: length of buffer in bytes
+ * @seed: start seed
+ *
+ * Returns 32bit hash.
+ */
+u32 arch_fast_hash(const void *data, u32 len, u32 seed)
{
+ return jhash(data, len, seed);
}
#endif /* __ASM_GENERIC_HASH_H */
diff --git a/include/linux/hash.h b/include/linux/hash.h
index d0494c3..6e8fb02 100644
--- a/include/linux/hash.h
+++ b/include/linux/hash.h
@@ -84,38 +84,4 @@ static inline u32 hash32_ptr(const void *ptr)
return (u32)val;
}
-struct fast_hash_ops {
- u32 (*hash)(const void *data, u32 len, u32 seed);
- u32 (*hash2)(const u32 *data, u32 len, u32 seed);
-};
-
-/**
- * arch_fast_hash - Caclulates a hash over a given buffer that can have
- * arbitrary size. This function will eventually use an
- * architecture-optimized hashing implementation if
- * available, and trades off distribution for speed.
- *
- * @data: buffer to hash
- * @len: length of buffer in bytes
- * @seed: start seed
- *
- * Returns 32bit hash.
- */
-extern u32 arch_fast_hash(const void *data, u32 len, u32 seed);
-
-/**
- * arch_fast_hash2 - Caclulates a hash over a given buffer that has a
- * size that is of a multiple of 32bit words. This
- * function will eventually use an architecture-
- * optimized hashing implementation if available,
- * and trades off distribution for speed.
- *
- * @data: buffer to hash (must be 32bit padded)
- * @len: number of 32bit words
- * @seed: start seed
- *
- * Returns 32bit hash.
- */
-extern u32 arch_fast_hash2(const u32 *data, u32 len, u32 seed);
-
#endif /* _LINUX_HASH_H */
diff --git a/lib/Makefile b/lib/Makefile
index 0211d2b..4b9baa4 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -26,7 +26,7 @@ obj-y += bcd.o div64.o sort.o parser.o halfmd4.o debug_locks.o random32.o \
bust_spinlocks.o hexdump.o kasprintf.o bitmap.o scatterlist.o \
gcd.o lcm.o list_sort.o uuid.o flex_array.o iovec.o clz_ctz.o \
bsearch.o find_last_bit.o find_next_bit.o llist.o memweight.o kfifo.o \
- percpu-refcount.o percpu_ida.o hash.o rhashtable.o reciprocal_div.o
+ percpu-refcount.o percpu_ida.o rhashtable.o reciprocal_div.o
obj-y += string_helpers.o
obj-$(CONFIG_TEST_STRING_HELPERS) += test-string_helpers.o
obj-y += kstrtox.o
diff --git a/lib/hash.c b/lib/hash.c
deleted file mode 100644
index fea973f..0000000
--- a/lib/hash.c
+++ /dev/null
@@ -1,39 +0,0 @@
-/* General purpose hashing library
- *
- * That's a start of a kernel hashing library, which can be extended
- * with further algorithms in future. arch_fast_hash{2,}() will
- * eventually resolve to an architecture optimized implementation.
- *
- * Copyright 2013 Francesco Fusco <ffusco@redhat.com>
- * Copyright 2013 Daniel Borkmann <dborkman@redhat.com>
- * Copyright 2013 Thomas Graf <tgraf@redhat.com>
- * Licensed under the GNU General Public License, version 2.0 (GPLv2)
- */
-
-#include <linux/jhash.h>
-#include <linux/hash.h>
-#include <linux/cache.h>
-
-static struct fast_hash_ops arch_hash_ops __read_mostly = {
- .hash = jhash,
- .hash2 = jhash2,
-};
-
-u32 arch_fast_hash(const void *data, u32 len, u32 seed)
-{
- return arch_hash_ops.hash(data, len, seed);
-}
-EXPORT_SYMBOL_GPL(arch_fast_hash);
-
-u32 arch_fast_hash2(const u32 *data, u32 len, u32 seed)
-{
- return arch_hash_ops.hash2(data, len, seed);
-}
-EXPORT_SYMBOL_GPL(arch_fast_hash2);
-
-static int __init hashlib_init(void)
-{
- setup_arch_fast_hash(&arch_hash_ops);
- return 0;
-}
-early_initcall(hashlib_init);
diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
index e0a7fef..79bc65d 100644
--- a/net/openvswitch/flow_table.c
+++ b/net/openvswitch/flow_table.c
@@ -366,7 +366,7 @@ static u32 flow_hash(const struct sw_flow_key *key, int key_start,
/* Make sure number of hash bytes are multiple of u32. */
BUILD_BUG_ON(sizeof(long) % sizeof(u32));
- return arch_fast_hash2(hash_key, hash_u32s, 0);
+ return arch_fast_hash(hash_key, hash_u32s, 0);
}
static int flow_key_start(const struct sw_flow_key *key)
--
1.9.3
^ 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