* Re: [patch net-next v3 02/17] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
From: Roopa Prabhu @ 2014-11-28 10:14 UTC (permalink / raw)
To: Scott Feldman
Cc: Jamal Hadi Salim, John Fastabend, Jiri Pirko, Netdev,
David S. Miller, nhorman@tuxdriver.com, Andy Gospodarek,
Thomas Graf, dborkman@redhat.com, ogerlitz@mellanox.com,
jesse@nicira.com, pshelar@nicira.com, azhou@nicira.com,
ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang, Eric Dumazet,
Florian Fainelli, John Linville, "j
In-Reply-To: <CAE4R7bD1Hi+fnKp-Sg6Tn4AcpOu2pwgEYecP8LVA1ioO4FkgRQ@mail.gmail.com>
On 11/25/14, 6:36 PM, Scott Feldman wrote:
> On Tue, Nov 25, 2014 at 6:50 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>> On 11/25/14 11:30, John Fastabend wrote:
>>> On 11/25/2014 08:18 AM, Jamal Hadi Salim wrote:
>>>> On 11/25/14 11:01, John Fastabend wrote:
>>>>> On 11/25/2014 07:38 AM, Jamal Hadi Salim wrote:
>>>>>> On 11/25/14 05:28, Jiri Pirko wrote:
>>>>>>> Do the work of parsing NDA_VLAN directly in rtnetlink code, pass
>>>>>>> simple
>>>>>>> u16 vid to drivers from there.
>>>>>>>
>>
>>> Actually (after having some coffee) this becomes much more useful
>>> if you return which items failed. Then you can slam the hardware
>>> with your 100 entries, probably a lot more then that, and come back
>>> later and clean it up.
>>>
>> Yes, that is the general use case.
>> Unfortunately at the moment we only return codes on a netlink set
>> direction - but would be a beauty if we could return what succeeded
>> and didnt in some form of vector.
>> Note: all is not lost because you can always do a get afterwards and
>> find what is missing if you got a return code of "partial success".
>> Just a little less efficient..
>>
>>
>>> We return a bitmask of which operations were successful. So if SW fails
>>> we have both bits cleared and we abort. When SW is successful we set the
>>> SW bit and try to program the HW. If its sucessful we set the HW bit if
>>> its not we abort with an err. Converting this to (1) is not much work
>>> just skip the abort.
>>>
>> Ok, guess i am gonna have to go stare at the code some more.
>> I thought we returned one of the error codes?
>> A bitmask would work for a single entry - because you have two
>> options add to h/ware and/or s/ware. So response is easy to encode.
>> But if i have 1000 and they are sparsely populated (think an indexed
>> table and i have indices 1, 23, 45, etc), then a bitmask would be
>> hard to use.
> I'm confused by this discussion. Do I have this right: You want to
> send 1000 RTM_NEWNEIGHs to PF_BRIDGE with both NTF_MASTER and NTF_SELF
> set such that 1000 new FBD entries are installed in both (SW) the
> bridge's FDB and (HW) the port driver's FDB. My first confusion is
> why do you want these FBD entries in bridge's FDB? We're offloading
> the switching to HW so HW should be handling fwd plane. If ctrl pkt
> make it to SW, it can learn those FDB entries; no need for manual
> install of FDB entry in SW. It seems to me you only want to use
> NTF_SELF to install the FDB entry in HW using the port driver. And an
> error code is returned for that install. Since there is only one
> target (NTF_SELF) there is no need for bitmask return.
>
scott, we do have such usecase today. ie , a fdb entry with both
NTF_MASTER and NTF_SELF set.
And these fdb entries can come from an external controller. The path to
get them to the hw is via the kernel.
The controller can use `bridge fdb add` to add the fdb entries to the
kernel (with NTF_MASTER) and also indicate in the same message to add
the fdb entry to hw (with NTF_SELF). And in this model it is assumed
that the kernel fdb and hw fdb are in sync.
^ permalink raw reply
* [PATCH] Documentation: bindings: net: DPAA corenet binding document
From: Madalin Bucur @ 2014-11-28 10:10 UTC (permalink / raw)
To: devicetree, linuxppc-dev, netdev
Cc: scottwood, Emilian.Medve, Igal.Liberman, Madalin Bucur
Add the device tree binding document for the DPAA corenet node
and DPAA Ethernet nodes.
Signed-off-by: Madalin Bucur <madalin.bucur@freescale.com>
---
Documentation/devicetree/bindings/net/fsl-dpaa.txt | 31 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/fsl-dpaa.txt
diff --git a/Documentation/devicetree/bindings/net/fsl-dpaa.txt b/Documentation/devicetree/bindings/net/fsl-dpaa.txt
new file mode 100644
index 0000000..822c668
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fsl-dpaa.txt
@@ -0,0 +1,31 @@
+*DPAA corenet
+
+The corenet bus containing all DPAA Ethernet nodes.
+
+Required property
+ - compatible: string property. Must include "fsl,dpaa". Can include
+ also "fsl,<SoC>-dpaa".
+
+Example:
+
+fsl,dpaa {
+ compatible = "fsl,p4080-dpaa", "fsl,dpaa";
+};
+
+*DPAA Ethernet
+
+DPAA Ethernet implements an Ethernet interface on top of the functionality
+offered by the DPAA accelerators: QMan, BMan, FMan. It contains a reference
+to the FMan MAC node used (dTSEC, TGEC, MEMAC). This construct is used by
+u-boot for the boot-time device tree fix-up.
+
+Required properties
+ - compatible: standard string property. Must include "fsl,dpa-ethernet".
+ - fsl,fman-mac: phandle that references a node describing the used DPAA MAC.
+
+Example:
+
+ethernet0 {
+ compatible = "fsl,dpa-ethernet";
+ fsl,fman-mac = <&enet0>;
+};
--
1.7.11.7
^ permalink raw reply related
* Re: [patch net-next v3 08/17] bridge: call netdev_sw_port_stp_update when bridge port STP status changes
From: Roopa Prabhu @ 2014-11-28 10:05 UTC (permalink / raw)
To: Scott Feldman
Cc: Jiri Pirko, Netdev, David S. Miller, nhorman@tuxdriver.com,
Andy Gospodarek, Thomas Graf, dborkman@redhat.com,
ogerlitz@mellanox.com, jesse@nicira.com, pshelar@nicira.com,
azhou@nicira.com, ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang,
Fastabend, John R, Eric Dumazet, Jamal Hadi Salim,
Florian Fainelli, John Linville
In-Reply-To: <CAE4R7bAiEyztdGo2BMVGXq9phfASHsMU+QW4oocTmr9=4antxw@mail.gmail.com>
On 11/25/14, 5:35 PM, Scott Feldman wrote:
> So offload is a little strong for this particular function.
I just meant the flag (or mode) that you introduced for the swdev.
(The name of that flag ... offload or not ...is still being discussed.
I tend to use the name offload because i was voting for it :).
> The
> bridge driver or external STP process (msptd) is still controlling STP
> state for the port and processing the BPDUs. When the state changes
> on the port, the bridge driver is letting HW know, that's it.
I understand that. In which case, we should not call it stp state.
It is just port state. And since it is yet another port attribute like
port priority,
we should be able to use the same api to offload it to hw just like the
other port attributes.
And, Thats why i tried to generalize all bridge port attribute set by
introducing one generic netdev_sw_port_set_attr api.
https://marc.info/?l=linux-netdev&m=141661018619712&w=2
And coming back to my original comment in this thread,
the port state should be offloaded to hw only when the swdev mode (or hw
offload mode ;) is set.
> If the
> port driver can't do anything with that notification, then it should
> not implement ndo_switch_port_stp_update. If it does implement
> ndo_switch_port_stp_update, then it can adjust its HW (e.g. disable
> port if BR_DISABLED, etc), and return err code if somehow it failed
> while adjusting HW.
>
> This is not offloading STP state ctrl plane to HW. The ctrl plane is
> kept in bridge driver (or mstpd) in SW. HW stays dumb in this model.
> The bridge currently has policy control to turn on/off STP per bridge
> and a netlink hook for external processes to change STP state.
>
> On Tue, Nov 25, 2014 at 12:48 PM, Roopa Prabhu
> <roopa@cumulusnetworks.com> wrote:
>> On 11/25/14, 2:28 AM, Jiri Pirko wrote:
>>> From: Scott Feldman <sfeldma@gmail.com>
>>>
>>> To notify switch driver of change in STP state of bridge port, add new
>>> .ndo op and provide switchdev wrapper func to call ndo op. Use it in
>>> bridge
>>> code then.
>>>
>>> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
>>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>>> ---
>>> v2->v3:
>>> -changed "sw" string to "switch" to avoid confusion
>>> v1->v2:
>>> -no change
>>> ---
>>> include/linux/netdevice.h | 5 +++++
>>> include/net/switchdev.h | 7 +++++++
>>> net/bridge/br_stp.c | 2 ++
>>> net/switchdev/switchdev.c | 19 +++++++++++++++++++
>>> 4 files changed, 33 insertions(+)
>>>
>>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>>> index ce096dc..66cb64e 100644
>>> --- a/include/linux/netdevice.h
>>> +++ b/include/linux/netdevice.h
>>> @@ -1024,6 +1024,9 @@ typedef u16 (*select_queue_fallback_t)(struct
>>> net_device *dev,
>>> * Called to get an ID of the switch chip this port is part of.
>>> * If driver implements this, it indicates that it represents a port
>>> * of a switch chip.
>>> + * int (*ndo_switch_port_stp_update)(struct net_device *dev, u8 state);
>>> + * Called to notify switch device port of bridge port STP
>>> + * state change.
>>> */
>>> struct net_device_ops {
>>> int (*ndo_init)(struct net_device *dev);
>>> @@ -1180,6 +1183,8 @@ struct net_device_ops {
>>> #ifdef CONFIG_NET_SWITCHDEV
>>> int (*ndo_switch_parent_id_get)(struct
>>> net_device *dev,
>>> struct
>>> netdev_phys_item_id *psid);
>>> + int (*ndo_switch_port_stp_update)(struct
>>> net_device *dev,
>>> + u8 state);
>>> #endif
>>> };
>>> diff --git a/include/net/switchdev.h b/include/net/switchdev.h
>>> index 7a52360..8a6d164 100644
>>> --- a/include/net/switchdev.h
>>> +++ b/include/net/switchdev.h
>>> @@ -16,6 +16,7 @@
>>> int netdev_switch_parent_id_get(struct net_device *dev,
>>> struct netdev_phys_item_id *psid);
>>> +int netdev_switch_port_stp_update(struct net_device *dev, u8 state);
>>> #else
>>> @@ -25,6 +26,12 @@ static inline int netdev_switch_parent_id_get(struct
>>> net_device *dev,
>>> return -EOPNOTSUPP;
>>> }
>>> +static inline int netdev_switch_port_stp_update(struct net_device *dev,
>>> + u8 state)
>>> +{
>>> + return -EOPNOTSUPP;
>>> +}
>>> +
>>> #endif
>>> #endif /* _LINUX_SWITCHDEV_H_ */
>>> diff --git a/net/bridge/br_stp.c b/net/bridge/br_stp.c
>>> index 2b047bc..35e016c 100644
>>> --- a/net/bridge/br_stp.c
>>> +++ b/net/bridge/br_stp.c
>>> @@ -12,6 +12,7 @@
>>> */
>>> #include <linux/kernel.h>
>>> #include <linux/rculist.h>
>>> +#include <net/switchdev.h>
>>> #include "br_private.h"
>>> #include "br_private_stp.h"
>>> @@ -39,6 +40,7 @@ void br_log_state(const struct net_bridge_port *p)
>>> void br_set_state(struct net_bridge_port *p, unsigned int state)
>>> {
>>> p->state = state;
>>> + netdev_switch_port_stp_update(p->dev, state);
>>> }
>>> /* called under bridge lock */
>>> diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
>>> index 66973de..d162b21 100644
>>> --- a/net/switchdev/switchdev.c
>>> +++ b/net/switchdev/switchdev.c
>>> @@ -31,3 +31,22 @@ int netdev_switch_parent_id_get(struct net_device *dev,
>>> return ops->ndo_switch_parent_id_get(dev, psid);
>>> }
>>> EXPORT_SYMBOL(netdev_switch_parent_id_get);
>>> +
>>> +/**
>>> + * netdev_switch_port_stp_update - Notify switch device port of STP
>>> + * state change
>>> + * @dev: port device
>>> + * @state: port STP state
>>> + *
>>> + * Notify switch device port of bridge port STP state change.
>>> + */
>>> +int netdev_switch_port_stp_update(struct net_device *dev, u8 state)
>>> +{
>>> + const struct net_device_ops *ops = dev->netdev_ops;
>>> +
>>> + if (!ops->ndo_switch_port_stp_update)
>>> + return -EOPNOTSUPP;
>>> + WARN_ON(!ops->ndo_switch_parent_id_get);
>>> + return ops->ndo_switch_port_stp_update(dev, state);
>>> +}
>>> +EXPORT_SYMBOL(netdev_switch_port_stp_update);
>>
>> This should also check if offload is enabled on the bridge/port ?
>>
^ permalink raw reply
* Re: [PATCH net] bpf: x86: fix epilogue generation for eBPF programs
From: Daniel Borkmann @ 2014-11-28 9:39 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Zi Shen Lim, Eric Dumazet, H. Peter Anvin,
Thomas Gleixner, Ingo Molnar, Network Development, LKML
In-Reply-To: <CAMEtUuyzDs2Nz8WHdEZXmY9JOZx=w2UwUF06Kq5qcgkaaRKs3A@mail.gmail.com>
On 11/28/2014 06:55 AM, Alexei Starovoitov wrote:
> On Thu, Nov 27, 2014 at 1:52 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
>> On 11/27/2014 06:02 AM, Alexei Starovoitov wrote:
>>>
>>> classic BPF has a restriction that last insn is always BPF_RET.
>>> eBPF doesn't have BPF_RET instruction and this restriction.
>>> It has BPF_EXIT insn which can appear anywhere in the program
>>> one or more times and it doesn't have to be last insn.
>>> Fix eBPF JIT to emit epilogue when first BPF_EXIT is seen
>>> and all other BPF_EXIT instructions will be emitted as jump.
>>>
>>> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
>>> ---
>>> Note, this bug is applicable only to native eBPF programs
>>> which first were introduced in 3.18, so no need to send it
>>> to stable and therefore no 'Fixes' tag.
>>
>> Btw, even if it's not sent to -stable, a 'Fixes:' tag is useful
>> information for backporting and regression tracking, preferably
>> always mentioned where it can clearly be identified.
>
> Well I didn't mention it, as I said, because I don't think it
> needs backporting. Otherwise with the tag the tools might
> pick it up automatically? Just a guess.
No, Dave selects -stable material on a case-by-case basis and bundles
it up eventually; after -net was merged, it's then pushed to -stable
by himself (see Documentation/networking/netdev-FAQ.txt +114). So the
comment below "---" is absolutely okay.
It can well be, that some people/companies cannot switch for various
reasons immediately to the next kernels, but nevertheless would like
to have a certain features included, so generally regression tracking
via 'Fixes:' tag is extremely useful/valuable. ;)
> Fixes: 622582786c9e ("net: filter: x86: internal BPF JIT")
...
>> Why this type change here? This seems a bit out of context (I would
>> have expected a mention of this in the commit message, otherwise).
>
> The reason for signed is the following:
> jmp offset to epilogue is computed as:
> jmp_offset = ctx->cleanup_addr - addrs[i]
> when cleanup_addr was always last insn it wasn't a problem,
> since result of subtraction was positive.
> Now, since epilogue will be in the middle of JITed
> code the jmps to epilogue may be negative
Ok, thanks for the clarification, Alexei.
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Bjørn Mork @ 2014-11-28 9:29 UTC (permalink / raw)
To: Enrico Mioso
Cc: Alex Strizhevsky, ShaojunMidge.Tan, Mingying.Zhu, youtux,
linux-usb, netdev, Eli.Britstein
In-Reply-To: <alpine.LNX.2.03.1411271932510.1548@gmail.com>
Enrico Mioso <mrkiko.rs@gmail.com> writes:
> What I suspect, is that all this mess started when Huawei introduce new
> firmware releases that changed something in the IPV6 support.
> Bjorn - do you remember when a guy called Thomas reported us a problem about an
> LTE huawei modem that wasn't working with huawei_cdc_ncm?
> And you then discovered the problem was originated from some changes in the
> ordering of cdc_ncm actions; what happened then?
> Did Thomas get his modem back to working state?
yes, that bug was fixed by
commit ff0992e9036e9810e7cd45234fa32ca1e79750e2
Author: Bjørn Mork <bjorn@mork.no>
Date: Mon Mar 17 16:25:18 2014 +0100
net: cdc_ncm: fix control message ordering
This is a context modified revert of commit 6a9612e2cb22
("net: cdc_ncm: remove ncm_parm field") which introduced
a NCM specification violation, causing setup errors for
some devices. These errors resulted in the device and
host disagreeing about shared settings, with complete
failure to communicate as the end result.
The NCM specification require that many of the NCM specific
control reuests are sent only while the NCM Data Interface
is in alternate setting 0. Reverting the commit ensures that
we follow this requirement.
Fixes: 6a9612e2cb22 ("net: cdc_ncm: remove ncm_parm field")
Reported-and-tested-by: Pasi Kärkkäinen <pasik@iki.fi>
Reported-by: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Bjørn
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Kevin Zhu @ 2014-11-28 9:25 UTC (permalink / raw)
To: Enrico Mioso
Cc: Alex Strizhevsky, Bjørn Mork, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Eli Britstein
In-Reply-To: <alpine.LNX.2.03.1411281014450.4101@gmail.com>
The only difference I can tell now is windows does not pack the NDP with
zeros, it just sends whatever the skb buffer has, except the alignment.
Regards,
Kevin
On 11/28/2014 05:17 PM, Enrico Mioso wrote:
> Sorry - resending message to all.
> Is the MAC right? In my case it was, but ... you never know.
> And - have you tried the promisc mode, just in case... don't know if this might
> even be implementedi n the driver, think not, but...
> I don't know what to think anymore.
> this ARP packet seems the same as with windows... but might be it's only my
> impression.
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-11-28 9:23 UTC (permalink / raw)
To: Enrico Mioso
Cc: Alex Strizhevsky, Bjørn Mork, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Eli Britstein
In-Reply-To: <alpine.LNX.2.03.1411281014450.4101@gmail.com>
Yes. The MACs are right. When I started Wireshark, promisc mode was set.
Regards,
Kevin
On 11/28/2014 05:17 PM, Enrico Mioso wrote:
> Sorry - resending message to all.
> Is the MAC right? In my case it was, but ... you never know.
> And - have you tried the promisc mode, just in case... don't know if this might
> even be implementedi n the driver, think not, but...
> I don't know what to think anymore.
> this ARP packet seems the same as with windows... but might be it's only my
> impression.
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 v7 6/8] net: can: c_can: Disable pins when CAN interface is down
From: Roger Quadros @ 2014-11-28 9:22 UTC (permalink / raw)
To: Marc Kleine-Budde, Linus Walleij
Cc: wg, Wolfram Sang, Tony Lindgren, Thomas Gleixner, Mugunthan V N,
George Cherian, Felipe Balbi, Sekhar Nori, Nishanth Menon,
Sergei Shtylyov, Linux-OMAP, linux-can, netdev@vger.kernel.org
In-Reply-To: <54779564.7010309@pengutronix.de>
On 27/11/14 23:19, Marc Kleine-Budde wrote:
> On 11/27/2014 02:26 PM, Linus Walleij wrote:
>> On Fri, Nov 14, 2014 at 4:40 PM, Roger Quadros <rogerq@ti.com> wrote:
>>
>>> DRA7 CAN IP suffers from a problem which causes it to be prevented
>>> from fully turning OFF (i.e. stuck in transition) if the module was
>>> disabled while there was traffic on the CAN_RX line.
>>>
>>> To work around this issue we select the SLEEP pin state by default
>>> on probe and use the DEFAULT pin state on CAN up and back to the
>>> SLEEP pin state on CAN down.
>>>
>>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>>
>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>
> Thanks, however the patch is already upstream.
>
>>
>> I see you figured it out all by yourselves :D
>>
>> (Sorry for being absent.)
>>
>>> +#include <linux/pinctrl/consumer.h>
>>> + pinctrl_pm_select_default_state(dev->dev.parent);
>>> + pinctrl_pm_select_sleep_state(dev->dev.parent);
>>> + pinctrl_pm_select_sleep_state(dev->dev.parent);
>>
>> NB: in drivers/base/pinctrl.c:
>>
>> #ifdef CONFIG_PM
>> /*
>> * If power management is enabled, we also look for the optional
>> * sleep and idle pin states, with semantics as defined in
>> * <linux/pinctrl/pinctrl-state.h>
>> */
>> dev->pins->sleep_state = pinctrl_lookup_state(dev->pins->p,
>> PINCTRL_STATE_SLEEP);
>>
>> So if these states are necessary for the driver to work, put
>> depends on PM or select PM in the Kconfig.
>
> Roger, you can prepare a patch, if needed.
As pinctrl sleep is an optional driver feature we don't need to do any changes.
For the DRA7 specific case, the platform configs ensure that PM is enabled.
cheers,
-roger
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-11-28 9:17 UTC (permalink / raw)
To: Kevin Zhu
Cc: Alex Strizhevsky, Bjørn Mork, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Eli Britstein
In-Reply-To: <54783A1D.3090607@audiocodes.com>
Sorry - resending message to all.
Is the MAC right? In my case it was, but ... you never know.
And - have you tried the promisc mode, just in case... don't know if this might
even be implementedi n the driver, think not, but...
I don't know what to think anymore.
this ARP packet seems the same as with windows... but might be it's only my
impression.
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Kevin Zhu @ 2014-11-28 9:02 UTC (permalink / raw)
To: Enrico Mioso
Cc: Alex Strizhevsky, Bjørn Mork, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Eli Britstein
In-Reply-To: <alpine.LNX.2.03.1411280944200.4040@gmail.com>
This is an ARP packet from Linux 32bit driver. See if anyone can tell
any mistake.
0000 6e 63 6d 68 10 00 a9 00 94 01 00 00 10 00 00 00 ncmh............
0010 6e 63 6d 30 20 00 00 00 00 00 00 00 00 00 00 00 ncm0 ...........
0020 6a 01 00 00 2a 00 00 00 00 00 00 00 00 00 00 00 j...*...........
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0160 00 00 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ................
0170 00 1e 10 1f 00 00 08 06 00 01 08 00 06 04 00 01 ................
0180 00 1e 10 1f 00 00 0a 71 ee 01 00 00 00 00 00 00 .......q........
0190 70 50 f8 4a
Regards,
Kevin
On 11/28/2014 04:45 PM, Enrico Mioso wrote:
> To test our 32-bit driver, you need at least Ubuntu 14.04 and install the 3.16
> kernel; or install a kernel >= 3.16 anyway, as our modification is based on the
> cdc_ncm.c file from the git tree for logical reason.
>
>
> On Fri, 28 Nov 2014, Kevin Zhu wrote:
>
> ==Date: Fri, 28 Nov 2014 09:37:30
> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
> ==To: Enrico Mioso <mrkiko.rs@gmail.com>
> ==Cc: Alex Strizhevsky <alexxst@gmail.com>, Bjørn Mork <bjorn@mork.no>,
> == 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>,
> == Eli Britstein <Eli.Britstein@audiocodes.com>
> ==Subject: Re: Is this 32-bit NCM?
> ==
> ==As the remainder (wNdpOutPayloadRemainder) is overwritten by the
> ==following lines, whose finally value is 0, I modified the code not to
> ==change it. Let it remain 2. And now the capture shows the Ethernet
> ==header offset is the same as windows, however, it's not working yet.
> ==
> == /* adjust TX-remainder according to NCM specification. */
> == ctx->tx_remainder = ((ctx->tx_remainder - eth_hlen) &
> == (ctx->tx_modulus - 1));
> ==
> ==
> ==Regards,
> ==Kevin
> ==
> ==On 11/28/2014 04:24 PM, Enrico Mioso wrote:
> ==> The driver effectively uses the wNdpOutDivisor indirectly - see standard
> ==> cdc_ncm deriver as in kernel git tree, line 490.
> ==>
> ==>
> ==> On Fri, 28 Nov 2014, Kevin Zhu wrote:
> ==>
> ==> ==Date: Fri, 28 Nov 2014 07:24:49
> ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
> ==> ==To: Alex Strizhevsky <alexxst@gmail.com>, Bjørn Mork <bjorn@mork.no>,
> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>
> ==> ==Cc: Enrico Mioso <mrkiko.rs@gmail.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>,
> ==> == Eli Britstein <Eli.Britstein@audiocodes.com>
> ==> ==Subject: Re: Is this 32-bit NCM?
> ==> ==
> ==> ==Hi all,
> ==> ==
> ==> ==I'm able to get the following prints with the original huawei_cdc_ncm driver
> ==> ==from Ubuntu 12.04.3. It keeps on printing. I'm also able to get an IP, but
> ==> ==no Internet access.
> ==> ==
> ==> ==^HCSQ:"WCDMA",64,59,55
> ==> ==
> ==> ==^DSFLOWRPT:0000000E,00000000,00000000,0000000000000000,0000000000000000,000
> ==> ==00000,00000000
> ==> ==
> ==> ==OK
> ==> ==
> ==> ==^NDISSTAT:1,,,"IPV4"
> ==> ==
> ==> ==^STIN: 1, 0, 0
> ==> ==
> ==> ==^DSFLOWRPT:00000010,00000000,00000000,0000000000000000,0000000000000000,000
> ==> ==00000,00000000
> ==> ==
> ==> ==^DSFLOWRPT:00000012,00000000,00000000,0000000000000000,0000000000000000,000
> ==> ==00000,00000000
> ==> ==
> ==> ==^DSFLOWRPT:00000014,00000000,00000000,0000000000000000,0000000000000000,000
> ==> ==00000,00000000
> ==> ==
> ==> ==^STIN: 1, 0, 0
> ==> ==
> ==> ==
> ==> ==...
> ==> ==^STIN: 1, 0, 0
> ==> ==
> ==> ==^DSFLOWRPT:0000008C,00000000,00000000,0000000000000B36,0000000000000000,000
> ==> ==00000,00000000
> ==> ==
> ==> ==^DSFLOWRPT:0000008E,00000000,00000000,0000000000000B36,0000000000000000,000
> ==> ==00000,00000000
> ==> ==
> ==> ==Regarding the alignment, I think we have some difference between Windows and
> ==> ==Linux. The spec says it should satisfy the following constraint.
> ==> ==
> ==> ==Offset % wNdpOutDivisor == wNdpOutPayloadRemainder (for OUT datagrams)
> ==> ==
> ==> ==It seems the Huawei device take the NDP offset (Ethernet Header Offset) as
> ==> ==the parameter 'Offset' in the above constraint. And in the Linux capture, it
> ==> ==does not comply with it.
> ==> ==
> ==> ==
> ==> ==dwNtbInMaxSize=131072 dwNtbOutMaxSize=16384 wNdpOutPayloadRemainder=2
> ==> ==wNdpOutDivisor=4 wNdpOutAlignment=4 wNtbOutMaxDatagrams=0 flags=0x1f
> ==> ==
> ==> ==Windows:
> ==> ==
> ==> ==0000 6e 63 6d 68 10 00 b6 00 7c 00 00 00 5c 00 00 00 ncmh....|...\...
> ==> ==0010 00 00 00 00 00 00 00 00 00 1e 10 1f 00 00 08 00 ................
> ==> ==0020 45 00 00 3c 00 9b 00 00 80 01 a0 fe 0a 71 a3 0e E..<.........q..
> ==> ==0030 ca 6c 21 3c 08 00 4b 4b 00 01 02 10 61 62 63 64 .l!<..KK....abcd
> ==> ==0040 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 efghijklmnopqrst
> ==> ==0050 75 76 77 61 62 63 64 65 66 67 68 69 6e 63 6d 30 uvwabcdefghincm0
> ==> ==0060 20 00 00 00 00 00 00 00 00 00 00 00 12 00 00 00 ...............
> ==> ==0070 4a 00 00 00 00 00 00 00 00 00 00 00 J...........
> ==> ==
> ==> ==Linux: (thought it's a 16bit format capture, but it's the same as 32bit,
> ==> ==regarding the alignment)
> ==> ==
> ==> ==0000 4e 43 4d 48 0c 00 40 00 e2 00 0c 00 4e 43 4d 30 NCMH..@.....NCM0
> ==> ==0010 10 00 00 00 b8 00 2a 00 00 00 00 00 00 00 00 00 ......*.........
> ==> ==0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==00b0 00 00 00 00 00 00 00 00 ff ff ff ff ff ff 00 1e ................
> ==> ==00c0 10 1f 00 00 08 06 00 01 08 00 06 04 00 01 00 1e ................
> ==> ==00d0 10 1f 00 00 0a 71 cc a6 00 00 00 00 00 00 70 50 .....q........pP
> ==> ==00e0 f8 49 .I
> ==> ==
> ==> ==
> ==> ==Regards,
> ==> ==Kevin
> ==> ==On 11/27/2014 08:36 PM, Alex Strizhevsky wrote:
> ==> == Adding my colleagues - Eli, Kevin & Midge.
> ==> ==
> ==> ==Any ideas are welcome ;)
> ==> ==
> ==> ==
> ==> ==On Thu, Nov 27, 2014 at 12:03 PM, Bjørn Mork <bjorn@mork.no> wrote:
> ==> == Enrico Mioso <mrkiko.rs@gmail.com> writes:
> ==> ==
> ==> == > Ok - we can arrive to some ocnclusions regarding the
> ==> == E3272.
> ==> == > First of all - the modem seems buggy enough to not be
> ==> == able to handle requests
> ==> == > for different formats. You need to unplug and re-plug
> ==> == it, but this is onlyan
> ==> == > impression and is reasonable.
> ==> == >
> ==> == > Then - the modem will accept to ndisdup the connection
> ==> == with
> ==> == > at^ndisdup=1,1,"internet"
> ==> == > but - if we use huawei_cdc_ncm + cdc_ncm we have no flow
> ==> == handling messages and
> ==> == > the modem stops here.
> ==> == > If we use the cdc_ncm 32-bit driver (modified) we get
> ==> == lotfs of
> ==> == > ^dsflorpt
> ==> == > that's how it should be.
> ==> == > So I think we can say that something is changing.
> ==> == > Then there's the alignment problem you mentioned in your
> ==> == previous reply. And
> ==> == > this is hard to solve.
> ==> == > could you try to help me understand where the problem
> ==> == is?
> ==> == > I feel like we are very close to the solution but
> ==> == something isn't working.
> ==> == > Or might be just try to change the 16 bit driver?
> ==> ==
> ==> ==If you use a recent version of the driver as a basis, then you
> ==> ==get the
> ==> ==CDC NCM NTB parameters in sysfs (if not, then you need to enable
> ==> ==debugging and look in the log for these values). For example:
> ==> ==
> ==> ==bjorn@nemi:~$ grep . /sys/class/net/wwan0/cdc_ncm/*
> ==> ==/sys/class/net/wwan0/cdc_ncm/bmNtbFormatsSupported:0x0001
> ==> ==/sys/class/net/wwan0/cdc_ncm/dwNtbInMaxSize:15360
> ==> ==/sys/class/net/wwan0/cdc_ncm/dwNtbOutMaxSize:15360
> ==> ==/sys/class/net/wwan0/cdc_ncm/min_tx_pkt:13824
> ==> ==/sys/class/net/wwan0/cdc_ncm/rx_max:15360
> ==> ==/sys/class/net/wwan0/cdc_ncm/tx_max:15360
> ==> ==/sys/class/net/wwan0/cdc_ncm/tx_timer_usecs:400
> ==> ==/sys/class/net/wwan0/cdc_ncm/wNdpInAlignment:4
> ==> ==/sys/class/net/wwan0/cdc_ncm/wNdpInDivisor:1
> ==> ==/sys/class/net/wwan0/cdc_ncm/wNdpInPayloadRemainder:0
> ==> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutAlignment:4
> ==> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutDivisor:32
> ==> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutPayloadRemainder:0
> ==> ==/sys/class/net/wwan0/cdc_ncm/wNtbOutMaxDatagrams:32
> ==> ==
> ==> ==
> ==> ==The possible problem I am thinking of is proper handling of the
> ==> ==wNdp*PayloadRemainder values. See section 3.3.4 "NCM Ethernet
> ==> ==Frame
> ==> ==Alignment" in the spec. Which is confusing as hell, but if I
> ==> ==understand
> ==> ==it correctly then we are supposed to align the start of the IP
> ==> ==packets
> ==> ==(the "payload", _not_ the ethernet frame) to a whole
> ==> ==wNdp*Divisor number
> ==> ==as long as the wNdp*PayloadRemainder is 0.
> ==> ==
> ==> ==
> ==> ==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
> ==> ==
> ==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-11-28 8:46 UTC (permalink / raw)
To: Enrico Mioso
Cc: Alex Strizhevsky, Bjørn Mork, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Eli Britstein
In-Reply-To: <alpine.LNX.2.03.1411280941350.4020@gmail.com>
You have been helping a lot. Thanks!
Regards,
Kevin
On 11/28/2014 04:42 PM, Enrico Mioso wrote:
> But you are still in 16-bit mode, right?
> Have you tried by chance in 32-bit mode? I am convinced this is not the problem
> ... but, justi n case?
> thank you Kevin for your work - and sorry for being not so helpful...
>
>
> On Fri, 28 Nov 2014, Kevin Zhu wrote:
>
> ==Date: Fri, 28 Nov 2014 09:37:30
> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
> ==To: Enrico Mioso <mrkiko.rs@gmail.com>
> ==Cc: Alex Strizhevsky <alexxst@gmail.com>, Bjørn Mork <bjorn@mork.no>,
> == 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>,
> == Eli Britstein <Eli.Britstein@audiocodes.com>
> ==Subject: Re: Is this 32-bit NCM?
> ==
> ==As the remainder (wNdpOutPayloadRemainder) is overwritten by the
> ==following lines, whose finally value is 0, I modified the code not to
> ==change it. Let it remain 2. And now the capture shows the Ethernet
> ==header offset is the same as windows, however, it's not working yet.
> ==
> == /* adjust TX-remainder according to NCM specification. */
> == ctx->tx_remainder = ((ctx->tx_remainder - eth_hlen) &
> == (ctx->tx_modulus - 1));
> ==
> ==
> ==Regards,
> ==Kevin
> ==
> ==On 11/28/2014 04:24 PM, Enrico Mioso wrote:
> ==> The driver effectively uses the wNdpOutDivisor indirectly - see standard
> ==> cdc_ncm deriver as in kernel git tree, line 490.
> ==>
> ==>
> ==> On Fri, 28 Nov 2014, Kevin Zhu wrote:
> ==>
> ==> ==Date: Fri, 28 Nov 2014 07:24:49
> ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
> ==> ==To: Alex Strizhevsky <alexxst@gmail.com>, Bjørn Mork <bjorn@mork.no>,
> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>
> ==> ==Cc: Enrico Mioso <mrkiko.rs@gmail.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>,
> ==> == Eli Britstein <Eli.Britstein@audiocodes.com>
> ==> ==Subject: Re: Is this 32-bit NCM?
> ==> ==
> ==> ==Hi all,
> ==> ==
> ==> ==I'm able to get the following prints with the original huawei_cdc_ncm driver
> ==> ==from Ubuntu 12.04.3. It keeps on printing. I'm also able to get an IP, but
> ==> ==no Internet access.
> ==> ==
> ==> ==^HCSQ:"WCDMA",64,59,55
> ==> ==
> ==> ==^DSFLOWRPT:0000000E,00000000,00000000,0000000000000000,0000000000000000,000
> ==> ==00000,00000000
> ==> ==
> ==> ==OK
> ==> ==
> ==> ==^NDISSTAT:1,,,"IPV4"
> ==> ==
> ==> ==^STIN: 1, 0, 0
> ==> ==
> ==> ==^DSFLOWRPT:00000010,00000000,00000000,0000000000000000,0000000000000000,000
> ==> ==00000,00000000
> ==> ==
> ==> ==^DSFLOWRPT:00000012,00000000,00000000,0000000000000000,0000000000000000,000
> ==> ==00000,00000000
> ==> ==
> ==> ==^DSFLOWRPT:00000014,00000000,00000000,0000000000000000,0000000000000000,000
> ==> ==00000,00000000
> ==> ==
> ==> ==^STIN: 1, 0, 0
> ==> ==
> ==> ==
> ==> ==...
> ==> ==^STIN: 1, 0, 0
> ==> ==
> ==> ==^DSFLOWRPT:0000008C,00000000,00000000,0000000000000B36,0000000000000000,000
> ==> ==00000,00000000
> ==> ==
> ==> ==^DSFLOWRPT:0000008E,00000000,00000000,0000000000000B36,0000000000000000,000
> ==> ==00000,00000000
> ==> ==
> ==> ==Regarding the alignment, I think we have some difference between Windows and
> ==> ==Linux. The spec says it should satisfy the following constraint.
> ==> ==
> ==> ==Offset % wNdpOutDivisor == wNdpOutPayloadRemainder (for OUT datagrams)
> ==> ==
> ==> ==It seems the Huawei device take the NDP offset (Ethernet Header Offset) as
> ==> ==the parameter 'Offset' in the above constraint. And in the Linux capture, it
> ==> ==does not comply with it.
> ==> ==
> ==> ==
> ==> ==dwNtbInMaxSize=131072 dwNtbOutMaxSize=16384 wNdpOutPayloadRemainder=2
> ==> ==wNdpOutDivisor=4 wNdpOutAlignment=4 wNtbOutMaxDatagrams=0 flags=0x1f
> ==> ==
> ==> ==Windows:
> ==> ==
> ==> ==0000 6e 63 6d 68 10 00 b6 00 7c 00 00 00 5c 00 00 00 ncmh....|...\...
> ==> ==0010 00 00 00 00 00 00 00 00 00 1e 10 1f 00 00 08 00 ................
> ==> ==0020 45 00 00 3c 00 9b 00 00 80 01 a0 fe 0a 71 a3 0e E..<.........q..
> ==> ==0030 ca 6c 21 3c 08 00 4b 4b 00 01 02 10 61 62 63 64 .l!<..KK....abcd
> ==> ==0040 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 efghijklmnopqrst
> ==> ==0050 75 76 77 61 62 63 64 65 66 67 68 69 6e 63 6d 30 uvwabcdefghincm0
> ==> ==0060 20 00 00 00 00 00 00 00 00 00 00 00 12 00 00 00 ...............
> ==> ==0070 4a 00 00 00 00 00 00 00 00 00 00 00 J...........
> ==> ==
> ==> ==Linux: (thought it's a 16bit format capture, but it's the same as 32bit,
> ==> ==regarding the alignment)
> ==> ==
> ==> ==0000 4e 43 4d 48 0c 00 40 00 e2 00 0c 00 4e 43 4d 30 NCMH..@.....NCM0
> ==> ==0010 10 00 00 00 b8 00 2a 00 00 00 00 00 00 00 00 00 ......*.........
> ==> ==0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==00b0 00 00 00 00 00 00 00 00 ff ff ff ff ff ff 00 1e ................
> ==> ==00c0 10 1f 00 00 08 06 00 01 08 00 06 04 00 01 00 1e ................
> ==> ==00d0 10 1f 00 00 0a 71 cc a6 00 00 00 00 00 00 70 50 .....q........pP
> ==> ==00e0 f8 49 .I
> ==> ==
> ==> ==
> ==> ==Regards,
> ==> ==Kevin
> ==> ==On 11/27/2014 08:36 PM, Alex Strizhevsky wrote:
> ==> == Adding my colleagues - Eli, Kevin & Midge.
> ==> ==
> ==> ==Any ideas are welcome ;)
> ==> ==
> ==> ==
> ==> ==On Thu, Nov 27, 2014 at 12:03 PM, Bjørn Mork <bjorn@mork.no> wrote:
> ==> == Enrico Mioso <mrkiko.rs@gmail.com> writes:
> ==> ==
> ==> == > Ok - we can arrive to some ocnclusions regarding the
> ==> == E3272.
> ==> == > First of all - the modem seems buggy enough to not be
> ==> == able to handle requests
> ==> == > for different formats. You need to unplug and re-plug
> ==> == it, but this is onlyan
> ==> == > impression and is reasonable.
> ==> == >
> ==> == > Then - the modem will accept to ndisdup the connection
> ==> == with
> ==> == > at^ndisdup=1,1,"internet"
> ==> == > but - if we use huawei_cdc_ncm + cdc_ncm we have no flow
> ==> == handling messages and
> ==> == > the modem stops here.
> ==> == > If we use the cdc_ncm 32-bit driver (modified) we get
> ==> == lotfs of
> ==> == > ^dsflorpt
> ==> == > that's how it should be.
> ==> == > So I think we can say that something is changing.
> ==> == > Then there's the alignment problem you mentioned in your
> ==> == previous reply. And
> ==> == > this is hard to solve.
> ==> == > could you try to help me understand where the problem
> ==> == is?
> ==> == > I feel like we are very close to the solution but
> ==> == something isn't working.
> ==> == > Or might be just try to change the 16 bit driver?
> ==> ==
> ==> ==If you use a recent version of the driver as a basis, then you
> ==> ==get the
> ==> ==CDC NCM NTB parameters in sysfs (if not, then you need to enable
> ==> ==debugging and look in the log for these values). For example:
> ==> ==
> ==> ==bjorn@nemi:~$ grep . /sys/class/net/wwan0/cdc_ncm/*
> ==> ==/sys/class/net/wwan0/cdc_ncm/bmNtbFormatsSupported:0x0001
> ==> ==/sys/class/net/wwan0/cdc_ncm/dwNtbInMaxSize:15360
> ==> ==/sys/class/net/wwan0/cdc_ncm/dwNtbOutMaxSize:15360
> ==> ==/sys/class/net/wwan0/cdc_ncm/min_tx_pkt:13824
> ==> ==/sys/class/net/wwan0/cdc_ncm/rx_max:15360
> ==> ==/sys/class/net/wwan0/cdc_ncm/tx_max:15360
> ==> ==/sys/class/net/wwan0/cdc_ncm/tx_timer_usecs:400
> ==> ==/sys/class/net/wwan0/cdc_ncm/wNdpInAlignment:4
> ==> ==/sys/class/net/wwan0/cdc_ncm/wNdpInDivisor:1
> ==> ==/sys/class/net/wwan0/cdc_ncm/wNdpInPayloadRemainder:0
> ==> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutAlignment:4
> ==> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutDivisor:32
> ==> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutPayloadRemainder:0
> ==> ==/sys/class/net/wwan0/cdc_ncm/wNtbOutMaxDatagrams:32
> ==> ==
> ==> ==
> ==> ==The possible problem I am thinking of is proper handling of the
> ==> ==wNdp*PayloadRemainder values. See section 3.3.4 "NCM Ethernet
> ==> ==Frame
> ==> ==Alignment" in the spec. Which is confusing as hell, but if I
> ==> ==understand
> ==> ==it correctly then we are supposed to align the start of the IP
> ==> ==packets
> ==> ==(the "payload", _not_ the ethernet frame) to a whole
> ==> ==wNdp*Divisor number
> ==> ==as long as the wNdp*PayloadRemainder is 0.
> ==> ==
> ==> ==
> ==> ==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
> ==> ==
> ==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-11-28 8:46 UTC (permalink / raw)
To: Enrico Mioso
Cc: Alex Strizhevsky, Bjørn Mork, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Eli Britstein
In-Reply-To: <alpine.LNX.2.03.1411280941350.4020@gmail.com>
No. I also tried the 32bit version. The result is the same.
Regards,
Kevin
On 11/28/2014 04:42 PM, Enrico Mioso wrote:
> But you are still in 16-bit mode, right?
> Have you tried by chance in 32-bit mode? I am convinced this is not the problem
> ... but, justi n case?
> thank you Kevin for your work - and sorry for being not so helpful...
>
>
> On Fri, 28 Nov 2014, Kevin Zhu wrote:
>
> ==Date: Fri, 28 Nov 2014 09:37:30
> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
> ==To: Enrico Mioso <mrkiko.rs@gmail.com>
> ==Cc: Alex Strizhevsky <alexxst@gmail.com>, Bjørn Mork <bjorn@mork.no>,
> == 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>,
> == Eli Britstein <Eli.Britstein@audiocodes.com>
> ==Subject: Re: Is this 32-bit NCM?
> ==
> ==As the remainder (wNdpOutPayloadRemainder) is overwritten by the
> ==following lines, whose finally value is 0, I modified the code not to
> ==change it. Let it remain 2. And now the capture shows the Ethernet
> ==header offset is the same as windows, however, it's not working yet.
> ==
> == /* adjust TX-remainder according to NCM specification. */
> == ctx->tx_remainder = ((ctx->tx_remainder - eth_hlen) &
> == (ctx->tx_modulus - 1));
> ==
> ==
> ==Regards,
> ==Kevin
> ==
> ==On 11/28/2014 04:24 PM, Enrico Mioso wrote:
> ==> The driver effectively uses the wNdpOutDivisor indirectly - see standard
> ==> cdc_ncm deriver as in kernel git tree, line 490.
> ==>
> ==>
> ==> On Fri, 28 Nov 2014, Kevin Zhu wrote:
> ==>
> ==> ==Date: Fri, 28 Nov 2014 07:24:49
> ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
> ==> ==To: Alex Strizhevsky <alexxst@gmail.com>, Bjørn Mork <bjorn@mork.no>,
> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>
> ==> ==Cc: Enrico Mioso <mrkiko.rs@gmail.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>,
> ==> == Eli Britstein <Eli.Britstein@audiocodes.com>
> ==> ==Subject: Re: Is this 32-bit NCM?
> ==> ==
> ==> ==Hi all,
> ==> ==
> ==> ==I'm able to get the following prints with the original huawei_cdc_ncm driver
> ==> ==from Ubuntu 12.04.3. It keeps on printing. I'm also able to get an IP, but
> ==> ==no Internet access.
> ==> ==
> ==> ==^HCSQ:"WCDMA",64,59,55
> ==> ==
> ==> ==^DSFLOWRPT:0000000E,00000000,00000000,0000000000000000,0000000000000000,000
> ==> ==00000,00000000
> ==> ==
> ==> ==OK
> ==> ==
> ==> ==^NDISSTAT:1,,,"IPV4"
> ==> ==
> ==> ==^STIN: 1, 0, 0
> ==> ==
> ==> ==^DSFLOWRPT:00000010,00000000,00000000,0000000000000000,0000000000000000,000
> ==> ==00000,00000000
> ==> ==
> ==> ==^DSFLOWRPT:00000012,00000000,00000000,0000000000000000,0000000000000000,000
> ==> ==00000,00000000
> ==> ==
> ==> ==^DSFLOWRPT:00000014,00000000,00000000,0000000000000000,0000000000000000,000
> ==> ==00000,00000000
> ==> ==
> ==> ==^STIN: 1, 0, 0
> ==> ==
> ==> ==
> ==> ==...
> ==> ==^STIN: 1, 0, 0
> ==> ==
> ==> ==^DSFLOWRPT:0000008C,00000000,00000000,0000000000000B36,0000000000000000,000
> ==> ==00000,00000000
> ==> ==
> ==> ==^DSFLOWRPT:0000008E,00000000,00000000,0000000000000B36,0000000000000000,000
> ==> ==00000,00000000
> ==> ==
> ==> ==Regarding the alignment, I think we have some difference between Windows and
> ==> ==Linux. The spec says it should satisfy the following constraint.
> ==> ==
> ==> ==Offset % wNdpOutDivisor == wNdpOutPayloadRemainder (for OUT datagrams)
> ==> ==
> ==> ==It seems the Huawei device take the NDP offset (Ethernet Header Offset) as
> ==> ==the parameter 'Offset' in the above constraint. And in the Linux capture, it
> ==> ==does not comply with it.
> ==> ==
> ==> ==
> ==> ==dwNtbInMaxSize=131072 dwNtbOutMaxSize=16384 wNdpOutPayloadRemainder=2
> ==> ==wNdpOutDivisor=4 wNdpOutAlignment=4 wNtbOutMaxDatagrams=0 flags=0x1f
> ==> ==
> ==> ==Windows:
> ==> ==
> ==> ==0000 6e 63 6d 68 10 00 b6 00 7c 00 00 00 5c 00 00 00 ncmh....|...\...
> ==> ==0010 00 00 00 00 00 00 00 00 00 1e 10 1f 00 00 08 00 ................
> ==> ==0020 45 00 00 3c 00 9b 00 00 80 01 a0 fe 0a 71 a3 0e E..<.........q..
> ==> ==0030 ca 6c 21 3c 08 00 4b 4b 00 01 02 10 61 62 63 64 .l!<..KK....abcd
> ==> ==0040 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 efghijklmnopqrst
> ==> ==0050 75 76 77 61 62 63 64 65 66 67 68 69 6e 63 6d 30 uvwabcdefghincm0
> ==> ==0060 20 00 00 00 00 00 00 00 00 00 00 00 12 00 00 00 ...............
> ==> ==0070 4a 00 00 00 00 00 00 00 00 00 00 00 J...........
> ==> ==
> ==> ==Linux: (thought it's a 16bit format capture, but it's the same as 32bit,
> ==> ==regarding the alignment)
> ==> ==
> ==> ==0000 4e 43 4d 48 0c 00 40 00 e2 00 0c 00 4e 43 4d 30 NCMH..@.....NCM0
> ==> ==0010 10 00 00 00 b8 00 2a 00 00 00 00 00 00 00 00 00 ......*.........
> ==> ==0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==> ==00b0 00 00 00 00 00 00 00 00 ff ff ff ff ff ff 00 1e ................
> ==> ==00c0 10 1f 00 00 08 06 00 01 08 00 06 04 00 01 00 1e ................
> ==> ==00d0 10 1f 00 00 0a 71 cc a6 00 00 00 00 00 00 70 50 .....q........pP
> ==> ==00e0 f8 49 .I
> ==> ==
> ==> ==
> ==> ==Regards,
> ==> ==Kevin
> ==> ==On 11/27/2014 08:36 PM, Alex Strizhevsky wrote:
> ==> == Adding my colleagues - Eli, Kevin & Midge.
> ==> ==
> ==> ==Any ideas are welcome ;)
> ==> ==
> ==> ==
> ==> ==On Thu, Nov 27, 2014 at 12:03 PM, Bjørn Mork <bjorn@mork.no> wrote:
> ==> == Enrico Mioso <mrkiko.rs@gmail.com> writes:
> ==> ==
> ==> == > Ok - we can arrive to some ocnclusions regarding the
> ==> == E3272.
> ==> == > First of all - the modem seems buggy enough to not be
> ==> == able to handle requests
> ==> == > for different formats. You need to unplug and re-plug
> ==> == it, but this is onlyan
> ==> == > impression and is reasonable.
> ==> == >
> ==> == > Then - the modem will accept to ndisdup the connection
> ==> == with
> ==> == > at^ndisdup=1,1,"internet"
> ==> == > but - if we use huawei_cdc_ncm + cdc_ncm we have no flow
> ==> == handling messages and
> ==> == > the modem stops here.
> ==> == > If we use the cdc_ncm 32-bit driver (modified) we get
> ==> == lotfs of
> ==> == > ^dsflorpt
> ==> == > that's how it should be.
> ==> == > So I think we can say that something is changing.
> ==> == > Then there's the alignment problem you mentioned in your
> ==> == previous reply. And
> ==> == > this is hard to solve.
> ==> == > could you try to help me understand where the problem
> ==> == is?
> ==> == > I feel like we are very close to the solution but
> ==> == something isn't working.
> ==> == > Or might be just try to change the 16 bit driver?
> ==> ==
> ==> ==If you use a recent version of the driver as a basis, then you
> ==> ==get the
> ==> ==CDC NCM NTB parameters in sysfs (if not, then you need to enable
> ==> ==debugging and look in the log for these values). For example:
> ==> ==
> ==> ==bjorn@nemi:~$ grep . /sys/class/net/wwan0/cdc_ncm/*
> ==> ==/sys/class/net/wwan0/cdc_ncm/bmNtbFormatsSupported:0x0001
> ==> ==/sys/class/net/wwan0/cdc_ncm/dwNtbInMaxSize:15360
> ==> ==/sys/class/net/wwan0/cdc_ncm/dwNtbOutMaxSize:15360
> ==> ==/sys/class/net/wwan0/cdc_ncm/min_tx_pkt:13824
> ==> ==/sys/class/net/wwan0/cdc_ncm/rx_max:15360
> ==> ==/sys/class/net/wwan0/cdc_ncm/tx_max:15360
> ==> ==/sys/class/net/wwan0/cdc_ncm/tx_timer_usecs:400
> ==> ==/sys/class/net/wwan0/cdc_ncm/wNdpInAlignment:4
> ==> ==/sys/class/net/wwan0/cdc_ncm/wNdpInDivisor:1
> ==> ==/sys/class/net/wwan0/cdc_ncm/wNdpInPayloadRemainder:0
> ==> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutAlignment:4
> ==> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutDivisor:32
> ==> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutPayloadRemainder:0
> ==> ==/sys/class/net/wwan0/cdc_ncm/wNtbOutMaxDatagrams:32
> ==> ==
> ==> ==
> ==> ==The possible problem I am thinking of is proper handling of the
> ==> ==wNdp*PayloadRemainder values. See section 3.3.4 "NCM Ethernet
> ==> ==Frame
> ==> ==Alignment" in the spec. Which is confusing as hell, but if I
> ==> ==understand
> ==> ==it correctly then we are supposed to align the start of the IP
> ==> ==packets
> ==> ==(the "payload", _not_ the ethernet frame) to a whole
> ==> ==wNdp*Divisor number
> ==> ==as long as the wNdp*PayloadRemainder is 0.
> ==> ==
> ==> ==
> ==> ==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
> ==> ==
> ==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-11-28 8:45 UTC (permalink / raw)
To: Kevin Zhu
Cc: Alex Strizhevsky, Bjørn Mork, Midge Shaojun Tan,
youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Eli Britstein
In-Reply-To: <54783443.50700-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 10531 bytes --]
To test our 32-bit driver, you need at least Ubuntu 14.04 and install the 3.16
kernel; or install a kernel >= 3.16 anyway, as our modification is based on the
cdc_ncm.c file from the git tree for logical reason.
On Fri, 28 Nov 2014, Kevin Zhu wrote:
==Date: Fri, 28 Nov 2014 09:37:30
==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==Cc: Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Bjørn Mork <bjorn-yOkvZcmFvRU@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>,
== Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==Subject: Re: Is this 32-bit NCM?
==
==As the remainder (wNdpOutPayloadRemainder) is overwritten by the
==following lines, whose finally value is 0, I modified the code not to
==change it. Let it remain 2. And now the capture shows the Ethernet
==header offset is the same as windows, however, it's not working yet.
==
== /* adjust TX-remainder according to NCM specification. */
== ctx->tx_remainder = ((ctx->tx_remainder - eth_hlen) &
== (ctx->tx_modulus - 1));
==
==
==Regards,
==Kevin
==
==On 11/28/2014 04:24 PM, Enrico Mioso wrote:
==> The driver effectively uses the wNdpOutDivisor indirectly - see standard
==> cdc_ncm deriver as in kernel git tree, line 490.
==>
==>
==> On Fri, 28 Nov 2014, Kevin Zhu wrote:
==>
==> ==Date: Fri, 28 Nov 2014 07:24:49
==> ==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==> ==To: Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>,
==> == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==> ==Cc: Enrico Mioso <mrkiko.rs-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>,
==> == Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==> ==Subject: Re: Is this 32-bit NCM?
==> ==
==> ==Hi all,
==> ==
==> ==I'm able to get the following prints with the original huawei_cdc_ncm driver
==> ==from Ubuntu 12.04.3. It keeps on printing. I'm also able to get an IP, but
==> ==no Internet access.
==> ==
==> ==^HCSQ:"WCDMA",64,59,55
==> ==
==> ==^DSFLOWRPT:0000000E,00000000,00000000,0000000000000000,0000000000000000,000
==> ==00000,00000000
==> ==
==> ==OK
==> ==
==> ==^NDISSTAT:1,,,"IPV4"
==> ==
==> ==^STIN: 1, 0, 0
==> ==
==> ==^DSFLOWRPT:00000010,00000000,00000000,0000000000000000,0000000000000000,000
==> ==00000,00000000
==> ==
==> ==^DSFLOWRPT:00000012,00000000,00000000,0000000000000000,0000000000000000,000
==> ==00000,00000000
==> ==
==> ==^DSFLOWRPT:00000014,00000000,00000000,0000000000000000,0000000000000000,000
==> ==00000,00000000
==> ==
==> ==^STIN: 1, 0, 0
==> ==
==> ==
==> ==...
==> ==^STIN: 1, 0, 0
==> ==
==> ==^DSFLOWRPT:0000008C,00000000,00000000,0000000000000B36,0000000000000000,000
==> ==00000,00000000
==> ==
==> ==^DSFLOWRPT:0000008E,00000000,00000000,0000000000000B36,0000000000000000,000
==> ==00000,00000000
==> ==
==> ==Regarding the alignment, I think we have some difference between Windows and
==> ==Linux. The spec says it should satisfy the following constraint.
==> ==
==> ==Offset % wNdpOutDivisor == wNdpOutPayloadRemainder (for OUT datagrams)
==> ==
==> ==It seems the Huawei device take the NDP offset (Ethernet Header Offset) as
==> ==the parameter 'Offset' in the above constraint. And in the Linux capture, it
==> ==does not comply with it.
==> ==
==> ==
==> ==dwNtbInMaxSize=131072 dwNtbOutMaxSize=16384 wNdpOutPayloadRemainder=2
==> ==wNdpOutDivisor=4 wNdpOutAlignment=4 wNtbOutMaxDatagrams=0 flags=0x1f
==> ==
==> ==Windows:
==> ==
==> ==0000 6e 63 6d 68 10 00 b6 00 7c 00 00 00 5c 00 00 00 ncmh....|...\...
==> ==0010 00 00 00 00 00 00 00 00 00 1e 10 1f 00 00 08 00 ................
==> ==0020 45 00 00 3c 00 9b 00 00 80 01 a0 fe 0a 71 a3 0e E..<.........q..
==> ==0030 ca 6c 21 3c 08 00 4b 4b 00 01 02 10 61 62 63 64 .l!<..KK....abcd
==> ==0040 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 efghijklmnopqrst
==> ==0050 75 76 77 61 62 63 64 65 66 67 68 69 6e 63 6d 30 uvwabcdefghincm0
==> ==0060 20 00 00 00 00 00 00 00 00 00 00 00 12 00 00 00 ...............
==> ==0070 4a 00 00 00 00 00 00 00 00 00 00 00 J...........
==> ==
==> ==Linux: (thought it's a 16bit format capture, but it's the same as 32bit,
==> ==regarding the alignment)
==> ==
==> ==0000 4e 43 4d 48 0c 00 40 00 e2 00 0c 00 4e 43 4d 30 NCMH..@.....NCM0
==> ==0010 10 00 00 00 b8 00 2a 00 00 00 00 00 00 00 00 00 ......*.........
==> ==0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==00b0 00 00 00 00 00 00 00 00 ff ff ff ff ff ff 00 1e ................
==> ==00c0 10 1f 00 00 08 06 00 01 08 00 06 04 00 01 00 1e ................
==> ==00d0 10 1f 00 00 0a 71 cc a6 00 00 00 00 00 00 70 50 .....q........pP
==> ==00e0 f8 49 .I
==> ==
==> ==
==> ==Regards,
==> ==Kevin
==> ==On 11/27/2014 08:36 PM, Alex Strizhevsky wrote:
==> == Adding my colleagues - Eli, Kevin & Midge.
==> ==
==> ==Any ideas are welcome ;)
==> ==
==> ==
==> ==On Thu, Nov 27, 2014 at 12:03 PM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote:
==> == Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
==> ==
==> == > Ok - we can arrive to some ocnclusions regarding the
==> == E3272.
==> == > First of all - the modem seems buggy enough to not be
==> == able to handle requests
==> == > for different formats. You need to unplug and re-plug
==> == it, but this is onlyan
==> == > impression and is reasonable.
==> == >
==> == > Then - the modem will accept to ndisdup the connection
==> == with
==> == > at^ndisdup=1,1,"internet"
==> == > but - if we use huawei_cdc_ncm + cdc_ncm we have no flow
==> == handling messages and
==> == > the modem stops here.
==> == > If we use the cdc_ncm 32-bit driver (modified) we get
==> == lotfs of
==> == > ^dsflorpt
==> == > that's how it should be.
==> == > So I think we can say that something is changing.
==> == > Then there's the alignment problem you mentioned in your
==> == previous reply. And
==> == > this is hard to solve.
==> == > could you try to help me understand where the problem
==> == is?
==> == > I feel like we are very close to the solution but
==> == something isn't working.
==> == > Or might be just try to change the 16 bit driver?
==> ==
==> ==If you use a recent version of the driver as a basis, then you
==> ==get the
==> ==CDC NCM NTB parameters in sysfs (if not, then you need to enable
==> ==debugging and look in the log for these values). For example:
==> ==
==> ==bjorn@nemi:~$ grep . /sys/class/net/wwan0/cdc_ncm/*
==> ==/sys/class/net/wwan0/cdc_ncm/bmNtbFormatsSupported:0x0001
==> ==/sys/class/net/wwan0/cdc_ncm/dwNtbInMaxSize:15360
==> ==/sys/class/net/wwan0/cdc_ncm/dwNtbOutMaxSize:15360
==> ==/sys/class/net/wwan0/cdc_ncm/min_tx_pkt:13824
==> ==/sys/class/net/wwan0/cdc_ncm/rx_max:15360
==> ==/sys/class/net/wwan0/cdc_ncm/tx_max:15360
==> ==/sys/class/net/wwan0/cdc_ncm/tx_timer_usecs:400
==> ==/sys/class/net/wwan0/cdc_ncm/wNdpInAlignment:4
==> ==/sys/class/net/wwan0/cdc_ncm/wNdpInDivisor:1
==> ==/sys/class/net/wwan0/cdc_ncm/wNdpInPayloadRemainder:0
==> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutAlignment:4
==> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutDivisor:32
==> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutPayloadRemainder:0
==> ==/sys/class/net/wwan0/cdc_ncm/wNtbOutMaxDatagrams:32
==> ==
==> ==
==> ==The possible problem I am thinking of is proper handling of the
==> ==wNdp*PayloadRemainder values. See section 3.3.4 "NCM Ethernet
==> ==Frame
==> ==Alignment" in the spec. Which is confusing as hell, but if I
==> ==understand
==> ==it correctly then we are supposed to align the start of the IP
==> ==packets
==> ==(the "payload", _not_ the ethernet frame) to a whole
==> ==wNdp*Divisor number
==> ==as long as the wNdp*PayloadRemainder is 0.
==> ==
==> ==
==> ==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
==> ==
==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-11-28 8:42 UTC (permalink / raw)
To: Kevin Zhu
Cc: Alex Strizhevsky, Bjørn Mork, Midge Shaojun Tan,
youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Eli Britstein
In-Reply-To: <54783443.50700-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 10532 bytes --]
But you are still in 16-bit mode, right?
Have you tried by chance in 32-bit mode? I am convinced this is not the problem
... but, justi n case?
thank you Kevin for your work - and sorry for being not so helpful...
On Fri, 28 Nov 2014, Kevin Zhu wrote:
==Date: Fri, 28 Nov 2014 09:37:30
==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==Cc: Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Bjørn Mork <bjorn-yOkvZcmFvRU@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>,
== Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==Subject: Re: Is this 32-bit NCM?
==
==As the remainder (wNdpOutPayloadRemainder) is overwritten by the
==following lines, whose finally value is 0, I modified the code not to
==change it. Let it remain 2. And now the capture shows the Ethernet
==header offset is the same as windows, however, it's not working yet.
==
== /* adjust TX-remainder according to NCM specification. */
== ctx->tx_remainder = ((ctx->tx_remainder - eth_hlen) &
== (ctx->tx_modulus - 1));
==
==
==Regards,
==Kevin
==
==On 11/28/2014 04:24 PM, Enrico Mioso wrote:
==> The driver effectively uses the wNdpOutDivisor indirectly - see standard
==> cdc_ncm deriver as in kernel git tree, line 490.
==>
==>
==> On Fri, 28 Nov 2014, Kevin Zhu wrote:
==>
==> ==Date: Fri, 28 Nov 2014 07:24:49
==> ==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==> ==To: Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>,
==> == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==> ==Cc: Enrico Mioso <mrkiko.rs-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>,
==> == Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==> ==Subject: Re: Is this 32-bit NCM?
==> ==
==> ==Hi all,
==> ==
==> ==I'm able to get the following prints with the original huawei_cdc_ncm driver
==> ==from Ubuntu 12.04.3. It keeps on printing. I'm also able to get an IP, but
==> ==no Internet access.
==> ==
==> ==^HCSQ:"WCDMA",64,59,55
==> ==
==> ==^DSFLOWRPT:0000000E,00000000,00000000,0000000000000000,0000000000000000,000
==> ==00000,00000000
==> ==
==> ==OK
==> ==
==> ==^NDISSTAT:1,,,"IPV4"
==> ==
==> ==^STIN: 1, 0, 0
==> ==
==> ==^DSFLOWRPT:00000010,00000000,00000000,0000000000000000,0000000000000000,000
==> ==00000,00000000
==> ==
==> ==^DSFLOWRPT:00000012,00000000,00000000,0000000000000000,0000000000000000,000
==> ==00000,00000000
==> ==
==> ==^DSFLOWRPT:00000014,00000000,00000000,0000000000000000,0000000000000000,000
==> ==00000,00000000
==> ==
==> ==^STIN: 1, 0, 0
==> ==
==> ==
==> ==...
==> ==^STIN: 1, 0, 0
==> ==
==> ==^DSFLOWRPT:0000008C,00000000,00000000,0000000000000B36,0000000000000000,000
==> ==00000,00000000
==> ==
==> ==^DSFLOWRPT:0000008E,00000000,00000000,0000000000000B36,0000000000000000,000
==> ==00000,00000000
==> ==
==> ==Regarding the alignment, I think we have some difference between Windows and
==> ==Linux. The spec says it should satisfy the following constraint.
==> ==
==> ==Offset % wNdpOutDivisor == wNdpOutPayloadRemainder (for OUT datagrams)
==> ==
==> ==It seems the Huawei device take the NDP offset (Ethernet Header Offset) as
==> ==the parameter 'Offset' in the above constraint. And in the Linux capture, it
==> ==does not comply with it.
==> ==
==> ==
==> ==dwNtbInMaxSize=131072 dwNtbOutMaxSize=16384 wNdpOutPayloadRemainder=2
==> ==wNdpOutDivisor=4 wNdpOutAlignment=4 wNtbOutMaxDatagrams=0 flags=0x1f
==> ==
==> ==Windows:
==> ==
==> ==0000 6e 63 6d 68 10 00 b6 00 7c 00 00 00 5c 00 00 00 ncmh....|...\...
==> ==0010 00 00 00 00 00 00 00 00 00 1e 10 1f 00 00 08 00 ................
==> ==0020 45 00 00 3c 00 9b 00 00 80 01 a0 fe 0a 71 a3 0e E..<.........q..
==> ==0030 ca 6c 21 3c 08 00 4b 4b 00 01 02 10 61 62 63 64 .l!<..KK....abcd
==> ==0040 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 efghijklmnopqrst
==> ==0050 75 76 77 61 62 63 64 65 66 67 68 69 6e 63 6d 30 uvwabcdefghincm0
==> ==0060 20 00 00 00 00 00 00 00 00 00 00 00 12 00 00 00 ...............
==> ==0070 4a 00 00 00 00 00 00 00 00 00 00 00 J...........
==> ==
==> ==Linux: (thought it's a 16bit format capture, but it's the same as 32bit,
==> ==regarding the alignment)
==> ==
==> ==0000 4e 43 4d 48 0c 00 40 00 e2 00 0c 00 4e 43 4d 30 NCMH..@.....NCM0
==> ==0010 10 00 00 00 b8 00 2a 00 00 00 00 00 00 00 00 00 ......*.........
==> ==0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==00b0 00 00 00 00 00 00 00 00 ff ff ff ff ff ff 00 1e ................
==> ==00c0 10 1f 00 00 08 06 00 01 08 00 06 04 00 01 00 1e ................
==> ==00d0 10 1f 00 00 0a 71 cc a6 00 00 00 00 00 00 70 50 .....q........pP
==> ==00e0 f8 49 .I
==> ==
==> ==
==> ==Regards,
==> ==Kevin
==> ==On 11/27/2014 08:36 PM, Alex Strizhevsky wrote:
==> == Adding my colleagues - Eli, Kevin & Midge.
==> ==
==> ==Any ideas are welcome ;)
==> ==
==> ==
==> ==On Thu, Nov 27, 2014 at 12:03 PM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote:
==> == Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
==> ==
==> == > Ok - we can arrive to some ocnclusions regarding the
==> == E3272.
==> == > First of all - the modem seems buggy enough to not be
==> == able to handle requests
==> == > for different formats. You need to unplug and re-plug
==> == it, but this is onlyan
==> == > impression and is reasonable.
==> == >
==> == > Then - the modem will accept to ndisdup the connection
==> == with
==> == > at^ndisdup=1,1,"internet"
==> == > but - if we use huawei_cdc_ncm + cdc_ncm we have no flow
==> == handling messages and
==> == > the modem stops here.
==> == > If we use the cdc_ncm 32-bit driver (modified) we get
==> == lotfs of
==> == > ^dsflorpt
==> == > that's how it should be.
==> == > So I think we can say that something is changing.
==> == > Then there's the alignment problem you mentioned in your
==> == previous reply. And
==> == > this is hard to solve.
==> == > could you try to help me understand where the problem
==> == is?
==> == > I feel like we are very close to the solution but
==> == something isn't working.
==> == > Or might be just try to change the 16 bit driver?
==> ==
==> ==If you use a recent version of the driver as a basis, then you
==> ==get the
==> ==CDC NCM NTB parameters in sysfs (if not, then you need to enable
==> ==debugging and look in the log for these values). For example:
==> ==
==> ==bjorn@nemi:~$ grep . /sys/class/net/wwan0/cdc_ncm/*
==> ==/sys/class/net/wwan0/cdc_ncm/bmNtbFormatsSupported:0x0001
==> ==/sys/class/net/wwan0/cdc_ncm/dwNtbInMaxSize:15360
==> ==/sys/class/net/wwan0/cdc_ncm/dwNtbOutMaxSize:15360
==> ==/sys/class/net/wwan0/cdc_ncm/min_tx_pkt:13824
==> ==/sys/class/net/wwan0/cdc_ncm/rx_max:15360
==> ==/sys/class/net/wwan0/cdc_ncm/tx_max:15360
==> ==/sys/class/net/wwan0/cdc_ncm/tx_timer_usecs:400
==> ==/sys/class/net/wwan0/cdc_ncm/wNdpInAlignment:4
==> ==/sys/class/net/wwan0/cdc_ncm/wNdpInDivisor:1
==> ==/sys/class/net/wwan0/cdc_ncm/wNdpInPayloadRemainder:0
==> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutAlignment:4
==> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutDivisor:32
==> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutPayloadRemainder:0
==> ==/sys/class/net/wwan0/cdc_ncm/wNtbOutMaxDatagrams:32
==> ==
==> ==
==> ==The possible problem I am thinking of is proper handling of the
==> ==wNdp*PayloadRemainder values. See section 3.3.4 "NCM Ethernet
==> ==Frame
==> ==Alignment" in the spec. Which is confusing as hell, but if I
==> ==understand
==> ==it correctly then we are supposed to align the start of the IP
==> ==packets
==> ==(the "payload", _not_ the ethernet frame) to a whole
==> ==wNdp*Divisor number
==> ==as long as the wNdp*PayloadRemainder is 0.
==> ==
==> ==
==> ==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
==> ==
==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 v6 34/46] virtio_net: disable mac write for virtio 1.0
From: Jason Wang @ 2014-11-28 8:40 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: thuth, rusty, netdev, linux-kernel, virtualization, dahi,
pbonzini, David Miller
In-Reply-To: <1417118789-18231-35-git-send-email-mst@redhat.com>
On Fri, Nov 28, 2014 at 4:10 AM, Michael S. Tsirkin <mst@redhat.com>
wrote:
> The spec states that mac in config space is only driver-writable in
> the
> legacy case. Fence writing it in virtnet_set_mac_address() in the
> virtio 1.0 case.
>
> Suggested-by: Cornelia Huck <cornelia.huck@de.ibm.com>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/net/virtio_net.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index c6a72d3..9ab3c50 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1030,7 +1030,8 @@ static int virtnet_set_mac_address(struct
> net_device *dev, void *p)
> "Failed to set mac address by vq command.\n");
> return -EINVAL;
> }
> - } else if (virtio_has_feature(vdev, VIRTIO_NET_F_MAC)) {
> + } else if (virtio_has_feature(vdev, VIRTIO_NET_F_MAC) &&
> + !virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) {
> unsigned int i;
>
> /* Naturally, this has an atomicity problem. */
> --
> MST
Does this mean there's no way to setting mac addres
if ctrl mac addr is disabled in virtio-1?
If yes, we'd better keep this compatibility somehow.
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-11-28 8:39 UTC (permalink / raw)
To: Kevin Zhu
Cc: Alex Strizhevsky, Bjørn Mork, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Eli Britstein
In-Reply-To: <547830EE.8060302@audiocodes.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 9633 bytes --]
Bj-rn, you where right.
I was thinking this was the classic compulsory switch from a bitness to an
higher one.
Sorry.
On Fri, 28 Nov 2014, Kevin Zhu wrote:
==Date: Fri, 28 Nov 2014 09:23:16
==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
==To: Enrico Mioso <mrkiko.rs@gmail.com>
==Cc: Alex Strizhevsky <alexxst@gmail.com>, Bjørn Mork <bjorn@mork.no>,
== 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>,
== Eli Britstein <Eli.Britstein@audiocodes.com>
==Subject: Re: Is this 32-bit NCM?
==
==It's an ping packet. Windows pads it with 'abcdef...'.
==
==Regards,
==Kevin
==
==On 11/28/2014 04:17 PM, Enrico Mioso wrote:
==> And...why in Windows we have this line?
==> 0050 75 76 77 61 62 63 64 65 66 67 68 69 6e 63 6d 30 uvwabcdefghincm0
==> Is this just padding stuff before the "ncm0" string?
==> So in particular a simple line needs to be modified in practice in the driver,
==> or am I totally misguised?
==> Is our "offset" parameter calculatedsuitably in the driver? Looking at it, any
==> comment appreciated.
==>
==>
==> On Fri, 28 Nov 2014, Kevin Zhu wrote:
==>
==> ==Date: Fri, 28 Nov 2014 07:24:49
==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
==> ==To: Alex Strizhevsky <alexxst@gmail.com>, Bjørn Mork <bjorn@mork.no>,
==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>
==> ==Cc: Enrico Mioso <mrkiko.rs@gmail.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>,
==> == Eli Britstein <Eli.Britstein@audiocodes.com>
==> ==Subject: Re: Is this 32-bit NCM?
==> ==
==> ==Hi all,
==> ==
==> ==I'm able to get the following prints with the original huawei_cdc_ncm driver
==> ==from Ubuntu 12.04.3. It keeps on printing. I'm also able to get an IP, but
==> ==no Internet access.
==> ==
==> ==^HCSQ:"WCDMA",64,59,55
==> ==
==> ==^DSFLOWRPT:0000000E,00000000,00000000,0000000000000000,0000000000000000,000
==> ==00000,00000000
==> ==
==> ==OK
==> ==
==> ==^NDISSTAT:1,,,"IPV4"
==> ==
==> ==^STIN: 1, 0, 0
==> ==
==> ==^DSFLOWRPT:00000010,00000000,00000000,0000000000000000,0000000000000000,000
==> ==00000,00000000
==> ==
==> ==^DSFLOWRPT:00000012,00000000,00000000,0000000000000000,0000000000000000,000
==> ==00000,00000000
==> ==
==> ==^DSFLOWRPT:00000014,00000000,00000000,0000000000000000,0000000000000000,000
==> ==00000,00000000
==> ==
==> ==^STIN: 1, 0, 0
==> ==
==> ==
==> ==...
==> ==^STIN: 1, 0, 0
==> ==
==> ==^DSFLOWRPT:0000008C,00000000,00000000,0000000000000B36,0000000000000000,000
==> ==00000,00000000
==> ==
==> ==^DSFLOWRPT:0000008E,00000000,00000000,0000000000000B36,0000000000000000,000
==> ==00000,00000000
==> ==
==> ==Regarding the alignment, I think we have some difference between Windows and
==> ==Linux. The spec says it should satisfy the following constraint.
==> ==
==> ==Offset % wNdpOutDivisor == wNdpOutPayloadRemainder (for OUT datagrams)
==> ==
==> ==It seems the Huawei device take the NDP offset (Ethernet Header Offset) as
==> ==the parameter 'Offset' in the above constraint. And in the Linux capture, it
==> ==does not comply with it.
==> ==
==> ==
==> ==dwNtbInMaxSize=131072 dwNtbOutMaxSize=16384 wNdpOutPayloadRemainder=2
==> ==wNdpOutDivisor=4 wNdpOutAlignment=4 wNtbOutMaxDatagrams=0 flags=0x1f
==> ==
==> ==Windows:
==> ==
==> ==0000 6e 63 6d 68 10 00 b6 00 7c 00 00 00 5c 00 00 00 ncmh....|...\...
==> ==0010 00 00 00 00 00 00 00 00 00 1e 10 1f 00 00 08 00 ................
==> ==0020 45 00 00 3c 00 9b 00 00 80 01 a0 fe 0a 71 a3 0e E..<.........q..
==> ==0030 ca 6c 21 3c 08 00 4b 4b 00 01 02 10 61 62 63 64 .l!<..KK....abcd
==> ==0040 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 efghijklmnopqrst
==> ==0050 75 76 77 61 62 63 64 65 66 67 68 69 6e 63 6d 30 uvwabcdefghincm0
==> ==0060 20 00 00 00 00 00 00 00 00 00 00 00 12 00 00 00 ...............
==> ==0070 4a 00 00 00 00 00 00 00 00 00 00 00 J...........
==> ==
==> ==Linux: (thought it's a 16bit format capture, but it's the same as 32bit,
==> ==regarding the alignment)
==> ==
==> ==0000 4e 43 4d 48 0c 00 40 00 e2 00 0c 00 4e 43 4d 30 NCMH..@.....NCM0
==> ==0010 10 00 00 00 b8 00 2a 00 00 00 00 00 00 00 00 00 ......*.........
==> ==0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==> ==00b0 00 00 00 00 00 00 00 00 ff ff ff ff ff ff 00 1e ................
==> ==00c0 10 1f 00 00 08 06 00 01 08 00 06 04 00 01 00 1e ................
==> ==00d0 10 1f 00 00 0a 71 cc a6 00 00 00 00 00 00 70 50 .....q........pP
==> ==00e0 f8 49 .I
==> ==
==> ==
==> ==Regards,
==> ==Kevin
==> ==On 11/27/2014 08:36 PM, Alex Strizhevsky wrote:
==> == Adding my colleagues - Eli, Kevin & Midge.
==> ==
==> ==Any ideas are welcome ;)
==> ==
==> ==
==> ==On Thu, Nov 27, 2014 at 12:03 PM, Bjørn Mork <bjorn@mork.no> wrote:
==> == Enrico Mioso <mrkiko.rs@gmail.com> writes:
==> ==
==> == > Ok - we can arrive to some ocnclusions regarding the
==> == E3272.
==> == > First of all - the modem seems buggy enough to not be
==> == able to handle requests
==> == > for different formats. You need to unplug and re-plug
==> == it, but this is onlyan
==> == > impression and is reasonable.
==> == >
==> == > Then - the modem will accept to ndisdup the connection
==> == with
==> == > at^ndisdup=1,1,"internet"
==> == > but - if we use huawei_cdc_ncm + cdc_ncm we have no flow
==> == handling messages and
==> == > the modem stops here.
==> == > If we use the cdc_ncm 32-bit driver (modified) we get
==> == lotfs of
==> == > ^dsflorpt
==> == > that's how it should be.
==> == > So I think we can say that something is changing.
==> == > Then there's the alignment problem you mentioned in your
==> == previous reply. And
==> == > this is hard to solve.
==> == > could you try to help me understand where the problem
==> == is?
==> == > I feel like we are very close to the solution but
==> == something isn't working.
==> == > Or might be just try to change the 16 bit driver?
==> ==
==> ==If you use a recent version of the driver as a basis, then you
==> ==get the
==> ==CDC NCM NTB parameters in sysfs (if not, then you need to enable
==> ==debugging and look in the log for these values). For example:
==> ==
==> ==bjorn@nemi:~$ grep . /sys/class/net/wwan0/cdc_ncm/*
==> ==/sys/class/net/wwan0/cdc_ncm/bmNtbFormatsSupported:0x0001
==> ==/sys/class/net/wwan0/cdc_ncm/dwNtbInMaxSize:15360
==> ==/sys/class/net/wwan0/cdc_ncm/dwNtbOutMaxSize:15360
==> ==/sys/class/net/wwan0/cdc_ncm/min_tx_pkt:13824
==> ==/sys/class/net/wwan0/cdc_ncm/rx_max:15360
==> ==/sys/class/net/wwan0/cdc_ncm/tx_max:15360
==> ==/sys/class/net/wwan0/cdc_ncm/tx_timer_usecs:400
==> ==/sys/class/net/wwan0/cdc_ncm/wNdpInAlignment:4
==> ==/sys/class/net/wwan0/cdc_ncm/wNdpInDivisor:1
==> ==/sys/class/net/wwan0/cdc_ncm/wNdpInPayloadRemainder:0
==> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutAlignment:4
==> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutDivisor:32
==> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutPayloadRemainder:0
==> ==/sys/class/net/wwan0/cdc_ncm/wNtbOutMaxDatagrams:32
==> ==
==> ==
==> ==The possible problem I am thinking of is proper handling of the
==> ==wNdp*PayloadRemainder values. See section 3.3.4 "NCM Ethernet
==> ==Frame
==> ==Alignment" in the spec. Which is confusing as hell, but if I
==> ==understand
==> ==it correctly then we are supposed to align the start of the IP
==> ==packets
==> ==(the "payload", _not_ the ethernet frame) to a whole
==> ==wNdp*Divisor number
==> ==as long as the wNdp*PayloadRemainder is 0.
==> ==
==> ==
==> ==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
==> ==
==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 v6 33/46] vhost/net: larger header for virtio 1.0
From: Jason Wang @ 2014-11-28 8:38 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: thuth, kvm, rusty, netdev, linux-kernel, virtualization, dahi,
pbonzini, David Miller
In-Reply-To: <1417118789-18231-34-git-send-email-mst@redhat.com>
On Fri, Nov 28, 2014 at 4:10 AM, Michael S. Tsirkin <mst@redhat.com>
wrote:
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/vhost/net.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index cae22f9..1ac58d0 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -1027,7 +1027,8 @@ static int vhost_net_set_features(struct
> vhost_net *n, u64 features)
> size_t vhost_hlen, sock_hlen, hdr_len;
> int i;
>
> - hdr_len = (features & (1 << VIRTIO_NET_F_MRG_RXBUF)) ?
> + hdr_len = (features & ((1ULL << VIRTIO_NET_F_MRG_RXBUF) |
> + (1ULL << VIRTIO_F_VERSION_1))) ?
> sizeof(struct virtio_net_hdr_mrg_rxbuf) :
> sizeof(struct virtio_net_hdr);
> if (features & (1 << VHOST_NET_F_VIRTIO_NET_HDR)) {
> --
> MST
>
Reviewed-by: Jason Wang <jasowang@redhat.com>
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Kevin Zhu @ 2014-11-28 8:37 UTC (permalink / raw)
To: Enrico Mioso
Cc: Alex Strizhevsky, Bjørn Mork, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Eli Britstein
In-Reply-To: <alpine.LNX.2.03.1411280923230.3997@gmail.com>
As the remainder (wNdpOutPayloadRemainder) is overwritten by the
following lines, whose finally value is 0, I modified the code not to
change it. Let it remain 2. And now the capture shows the Ethernet
header offset is the same as windows, however, it's not working yet.
/* adjust TX-remainder according to NCM specification. */
ctx->tx_remainder = ((ctx->tx_remainder - eth_hlen) &
(ctx->tx_modulus - 1));
Regards,
Kevin
On 11/28/2014 04:24 PM, Enrico Mioso wrote:
> The driver effectively uses the wNdpOutDivisor indirectly - see standard
> cdc_ncm deriver as in kernel git tree, line 490.
>
>
> On Fri, 28 Nov 2014, Kevin Zhu wrote:
>
> ==Date: Fri, 28 Nov 2014 07:24:49
> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
> ==To: Alex Strizhevsky <alexxst@gmail.com>, Bjørn Mork <bjorn@mork.no>,
> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>
> ==Cc: Enrico Mioso <mrkiko.rs@gmail.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>,
> == Eli Britstein <Eli.Britstein@audiocodes.com>
> ==Subject: Re: Is this 32-bit NCM?
> ==
> ==Hi all,
> ==
> ==I'm able to get the following prints with the original huawei_cdc_ncm driver
> ==from Ubuntu 12.04.3. It keeps on printing. I'm also able to get an IP, but
> ==no Internet access.
> ==
> ==^HCSQ:"WCDMA",64,59,55
> ==
> ==^DSFLOWRPT:0000000E,00000000,00000000,0000000000000000,0000000000000000,000
> ==00000,00000000
> ==
> ==OK
> ==
> ==^NDISSTAT:1,,,"IPV4"
> ==
> ==^STIN: 1, 0, 0
> ==
> ==^DSFLOWRPT:00000010,00000000,00000000,0000000000000000,0000000000000000,000
> ==00000,00000000
> ==
> ==^DSFLOWRPT:00000012,00000000,00000000,0000000000000000,0000000000000000,000
> ==00000,00000000
> ==
> ==^DSFLOWRPT:00000014,00000000,00000000,0000000000000000,0000000000000000,000
> ==00000,00000000
> ==
> ==^STIN: 1, 0, 0
> ==
> ==
> ==...
> ==^STIN: 1, 0, 0
> ==
> ==^DSFLOWRPT:0000008C,00000000,00000000,0000000000000B36,0000000000000000,000
> ==00000,00000000
> ==
> ==^DSFLOWRPT:0000008E,00000000,00000000,0000000000000B36,0000000000000000,000
> ==00000,00000000
> ==
> ==Regarding the alignment, I think we have some difference between Windows and
> ==Linux. The spec says it should satisfy the following constraint.
> ==
> ==Offset % wNdpOutDivisor == wNdpOutPayloadRemainder (for OUT datagrams)
> ==
> ==It seems the Huawei device take the NDP offset (Ethernet Header Offset) as
> ==the parameter 'Offset' in the above constraint. And in the Linux capture, it
> ==does not comply with it.
> ==
> ==
> ==dwNtbInMaxSize=131072 dwNtbOutMaxSize=16384 wNdpOutPayloadRemainder=2
> ==wNdpOutDivisor=4 wNdpOutAlignment=4 wNtbOutMaxDatagrams=0 flags=0x1f
> ==
> ==Windows:
> ==
> ==0000 6e 63 6d 68 10 00 b6 00 7c 00 00 00 5c 00 00 00 ncmh....|...\...
> ==0010 00 00 00 00 00 00 00 00 00 1e 10 1f 00 00 08 00 ................
> ==0020 45 00 00 3c 00 9b 00 00 80 01 a0 fe 0a 71 a3 0e E..<.........q..
> ==0030 ca 6c 21 3c 08 00 4b 4b 00 01 02 10 61 62 63 64 .l!<..KK....abcd
> ==0040 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 efghijklmnopqrst
> ==0050 75 76 77 61 62 63 64 65 66 67 68 69 6e 63 6d 30 uvwabcdefghincm0
> ==0060 20 00 00 00 00 00 00 00 00 00 00 00 12 00 00 00 ...............
> ==0070 4a 00 00 00 00 00 00 00 00 00 00 00 J...........
> ==
> ==Linux: (thought it's a 16bit format capture, but it's the same as 32bit,
> ==regarding the alignment)
> ==
> ==0000 4e 43 4d 48 0c 00 40 00 e2 00 0c 00 4e 43 4d 30 NCMH..@.....NCM0
> ==0010 10 00 00 00 b8 00 2a 00 00 00 00 00 00 00 00 00 ......*.........
> ==0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ==00b0 00 00 00 00 00 00 00 00 ff ff ff ff ff ff 00 1e ................
> ==00c0 10 1f 00 00 08 06 00 01 08 00 06 04 00 01 00 1e ................
> ==00d0 10 1f 00 00 0a 71 cc a6 00 00 00 00 00 00 70 50 .....q........pP
> ==00e0 f8 49 .I
> ==
> ==
> ==Regards,
> ==Kevin
> ==On 11/27/2014 08:36 PM, Alex Strizhevsky wrote:
> == Adding my colleagues - Eli, Kevin & Midge.
> ==
> ==Any ideas are welcome ;)
> ==
> ==
> ==On Thu, Nov 27, 2014 at 12:03 PM, Bjørn Mork <bjorn@mork.no> wrote:
> == Enrico Mioso <mrkiko.rs@gmail.com> writes:
> ==
> == > Ok - we can arrive to some ocnclusions regarding the
> == E3272.
> == > First of all - the modem seems buggy enough to not be
> == able to handle requests
> == > for different formats. You need to unplug and re-plug
> == it, but this is onlyan
> == > impression and is reasonable.
> == >
> == > Then - the modem will accept to ndisdup the connection
> == with
> == > at^ndisdup=1,1,"internet"
> == > but - if we use huawei_cdc_ncm + cdc_ncm we have no flow
> == handling messages and
> == > the modem stops here.
> == > If we use the cdc_ncm 32-bit driver (modified) we get
> == lotfs of
> == > ^dsflorpt
> == > that's how it should be.
> == > So I think we can say that something is changing.
> == > Then there's the alignment problem you mentioned in your
> == previous reply. And
> == > this is hard to solve.
> == > could you try to help me understand where the problem
> == is?
> == > I feel like we are very close to the solution but
> == something isn't working.
> == > Or might be just try to change the 16 bit driver?
> ==
> ==If you use a recent version of the driver as a basis, then you
> ==get the
> ==CDC NCM NTB parameters in sysfs (if not, then you need to enable
> ==debugging and look in the log for these values). For example:
> ==
> ==bjorn@nemi:~$ grep . /sys/class/net/wwan0/cdc_ncm/*
> ==/sys/class/net/wwan0/cdc_ncm/bmNtbFormatsSupported:0x0001
> ==/sys/class/net/wwan0/cdc_ncm/dwNtbInMaxSize:15360
> ==/sys/class/net/wwan0/cdc_ncm/dwNtbOutMaxSize:15360
> ==/sys/class/net/wwan0/cdc_ncm/min_tx_pkt:13824
> ==/sys/class/net/wwan0/cdc_ncm/rx_max:15360
> ==/sys/class/net/wwan0/cdc_ncm/tx_max:15360
> ==/sys/class/net/wwan0/cdc_ncm/tx_timer_usecs:400
> ==/sys/class/net/wwan0/cdc_ncm/wNdpInAlignment:4
> ==/sys/class/net/wwan0/cdc_ncm/wNdpInDivisor:1
> ==/sys/class/net/wwan0/cdc_ncm/wNdpInPayloadRemainder:0
> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutAlignment:4
> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutDivisor:32
> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutPayloadRemainder:0
> ==/sys/class/net/wwan0/cdc_ncm/wNtbOutMaxDatagrams:32
> ==
> ==
> ==The possible problem I am thinking of is proper handling of the
> ==wNdp*PayloadRemainder values. See section 3.3.4 "NCM Ethernet
> ==Frame
> ==Alignment" in the spec. Which is confusing as hell, but if I
> ==understand
> ==it correctly then we are supposed to align the start of the IP
> ==packets
> ==(the "payload", _not_ the ethernet frame) to a whole
> ==wNdp*Divisor number
> ==as long as the wNdp*PayloadRemainder is 0.
> ==
> ==
> ==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
> ==
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 v6 30/46] vhost/net: force len for TX to host endian
From: Jason Wang @ 2014-11-28 8:36 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: thuth, kvm, rusty, netdev, linux-kernel, virtualization, dahi,
pbonzini, David Miller
In-Reply-To: <1417118789-18231-31-git-send-email-mst@redhat.com>
On Fri, Nov 28, 2014 at 4:10 AM, Michael S. Tsirkin <mst@redhat.com>
wrote:
> vhost/net keeps a copy of some used ring but (ab)uses length
> field for internal house-keeping. This works because
> for tx used length is always 0.
> Suppress sparse errors: we use native endian-ness internally but never
> expose it to guest.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/vhost/net.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 8dae2f7..dce5c58 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -48,15 +48,15 @@ MODULE_PARM_DESC(experimental_zcopytx, "Enable
> Zero Copy TX;"
> * status internally; used for zerocopy tx only.
> */
> /* Lower device DMA failed */
> -#define VHOST_DMA_FAILED_LEN 3
> +#define VHOST_DMA_FAILED_LEN ((__force __virtio32)3)
> /* Lower device DMA done */
> -#define VHOST_DMA_DONE_LEN 2
> +#define VHOST_DMA_DONE_LEN ((__force __virtio32)2)
> /* Lower device DMA in progress */
> -#define VHOST_DMA_IN_PROGRESS 1
> +#define VHOST_DMA_IN_PROGRESS ((__force __virtio32)1)
> /* Buffer unused */
> -#define VHOST_DMA_CLEAR_LEN 0
> +#define VHOST_DMA_CLEAR_LEN ((__force __virtio32)0)
>
> -#define VHOST_DMA_IS_DONE(len) ((len) >= VHOST_DMA_DONE_LEN)
> +#define VHOST_DMA_IS_DONE(len) ((__force u32)(len) >= (__force
> u32)VHOST_DMA_DONE_LEN)
>
> enum {
> VHOST_NET_FEATURES = VHOST_FEATURES |
> --
> MST
Reviewed-by: Jason Wang <jasowang@redhat.com>
^ permalink raw reply
* Re: [PATCH v6 29/46] vhost: add memory access wrappers
From: Jason Wang @ 2014-11-28 8:35 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: thuth, kvm, rusty, netdev, linux-kernel, virtualization, dahi,
pbonzini, David Miller
In-Reply-To: <1417118789-18231-30-git-send-email-mst@redhat.com>
On Fri, Nov 28, 2014 at 4:10 AM, Michael S. Tsirkin <mst@redhat.com>
wrote:
> Add guest memory access wrappers to handle virtio endianness
> conversions.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/vhost/vhost.h | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
> index c624b09..1f321fd 100644
> --- a/drivers/vhost/vhost.h
> +++ b/drivers/vhost/vhost.h
> @@ -176,4 +176,35 @@ static inline int vhost_has_feature(struct
> vhost_virtqueue *vq, int bit)
> {
> return vq->acked_features & (1ULL << bit);
> }
> +
> +/* Memory accessors */
> +static inline u16 vhost16_to_cpu(struct vhost_virtqueue *vq,
> __virtio16 val)
> +{
> + return __virtio16_to_cpu(vhost_has_feature(vq, VIRTIO_F_VERSION_1),
> val);
> +}
> +
> +static inline __virtio16 cpu_to_vhost16(struct vhost_virtqueue *vq,
> u16 val)
> +{
> + return __cpu_to_virtio16(vhost_has_feature(vq, VIRTIO_F_VERSION_1),
> val);
> +}
> +
> +static inline u32 vhost32_to_cpu(struct vhost_virtqueue *vq,
> __virtio32 val)
> +{
> + return __virtio32_to_cpu(vhost_has_feature(vq, VIRTIO_F_VERSION_1),
> val);
> +}
> +
> +static inline __virtio32 cpu_to_vhost32(struct vhost_virtqueue *vq,
> u32 val)
> +{
> + return __cpu_to_virtio32(vhost_has_feature(vq, VIRTIO_F_VERSION_1),
> val);
> +}
> +
> +static inline u64 vhost64_to_cpu(struct vhost_virtqueue *vq,
> __virtio64 val)
> +{
> + return __virtio64_to_cpu(vhost_has_feature(vq, VIRTIO_F_VERSION_1),
> val);
> +}
> +
> +static inline __virtio64 cpu_to_vhost64(struct vhost_virtqueue *vq,
> u64 val)
> +{
> + return __cpu_to_virtio64(vhost_has_feature(vq, VIRTIO_F_VERSION_1),
> val);
> +}
> #endif
> --
> MST
Reviewed-by: Jason Wang <jasowang@redhat.com>
^ permalink raw reply
* Re: [PATCH v6 28/46] vhost: make features 64 bit
From: Jason Wang @ 2014-11-28 8:32 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: thuth, kvm, rusty, netdev, linux-kernel, virtualization, dahi,
pbonzini, David Miller
In-Reply-To: <1417118789-18231-29-git-send-email-mst@redhat.com>
On Fri, Nov 28, 2014 at 4:10 AM, Michael S. Tsirkin <mst@redhat.com>
wrote:
> We need to use bit 32 for virtio 1.0
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/vhost/vhost.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
> index 3eda654..c624b09 100644
> --- a/drivers/vhost/vhost.h
> +++ b/drivers/vhost/vhost.h
> @@ -106,7 +106,7 @@ struct vhost_virtqueue {
> /* Protected by virtqueue mutex. */
> struct vhost_memory *memory;
> void *private_data;
> - unsigned acked_features;
> + u64 acked_features;
> /* Log write descriptors */
> void __user *log_base;
> struct vhost_log *log;
> @@ -174,6 +174,6 @@ enum {
>
> static inline int vhost_has_feature(struct vhost_virtqueue *vq, int
> bit)
> {
> - return vq->acked_features & (1 << bit);
> + return vq->acked_features & (1ULL << bit);
> }
> #endif
> --
> MST
Reviewed-by: Jason Wang <jasowang@redhat.com>
^ permalink raw reply
* Re: [PATCH v6 26/46] virtio_net: bigger header when VERSION_1 is set
From: Jason Wang @ 2014-11-28 8:31 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: thuth, rusty, netdev, linux-kernel, virtualization, dahi,
pbonzini, David Miller
In-Reply-To: <1417118789-18231-27-git-send-email-mst@redhat.com>
On Fri, Nov 28, 2014 at 4:10 AM, Michael S. Tsirkin <mst@redhat.com>
wrote:
> With VERSION_1 virtio_net uses same header size
> whether mergeable buffers are enabled or not.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
> ---
> drivers/net/virtio_net.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 098f443..a0e64cf 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1805,7 +1805,8 @@ static int virtnet_probe(struct virtio_device
> *vdev)
> if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF))
> vi->mergeable_rx_bufs = true;
>
> - if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF))
> + if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF) ||
> + virtio_has_feature(vdev, VIRTIO_F_VERSION_1))
> vi->hdr_len = sizeof(struct virtio_net_hdr_mrg_rxbuf);
> else
> vi->hdr_len = sizeof(struct virtio_net_hdr);
> --
> MST
Reviewed-by: Jason Wang <jasowang@redhat.com>
^ permalink raw reply
* Re: [PATCH v6 25/46] virtio_net: stricter short buffer length checks
From: Jason Wang @ 2014-11-28 8:31 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: thuth, rusty, netdev, linux-kernel, virtualization, dahi,
pbonzini, David Miller
In-Reply-To: <1417118789-18231-26-git-send-email-mst@redhat.com>
On Fri, Nov 28, 2014 at 4:09 AM, Michael S. Tsirkin <mst@redhat.com>
wrote:
> Our buffer length check is not strict enough for mergeable
> buffers: buffer can still be shorter that header + address
> by 2 bytes.
>
> Fix that up.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
> ---
> drivers/net/virtio_net.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 516f2cb..098f443 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -437,7 +437,7 @@ static void receive_buf(struct virtnet_info *vi,
> struct receive_queue *rq,
> struct sk_buff *skb;
> struct virtio_net_hdr_mrg_rxbuf *hdr;
>
> - if (unlikely(len < sizeof(struct virtio_net_hdr) + ETH_HLEN)) {
> + if (unlikely(len < vi->hdr_len + ETH_HLEN)) {
> pr_debug("%s: short packet %i\n", dev->name, len);
> dev->stats.rx_length_errors++;
> if (vi->mergeable_rx_bufs) {
> --
> MST
Reviewed-by: Jason Wang <jasowang@redhat.com>
^ permalink raw reply
* Re: [PATCH v6 24/46] virtio_net: get rid of virtio_net_hdr/skb_vnet_hdr
From: Jason Wang @ 2014-11-28 8:30 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: thuth, rusty, netdev, linux-kernel, virtualization, dahi,
pbonzini, David Miller
In-Reply-To: <1417118789-18231-25-git-send-email-mst@redhat.com>
On Fri, Nov 28, 2014 at 4:09 AM, Michael S. Tsirkin <mst@redhat.com>
wrote:
> virtio 1.0 doesn't use virtio_net_hdr anymore, and in fact, it's not
> really useful since virtio_net_hdr_mrg_rxbuf includes that as the
> first
> field anyway.
>
> Let's drop it, precalculate header len and store within vi instead.
>
> This way we can also remove struct skb_vnet_hdr.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
> ---
> drivers/net/virtio_net.c | 90
> ++++++++++++++++++++++--------------------------
> 1 file changed, 41 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 1630c21..516f2cb 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -123,6 +123,9 @@ struct virtnet_info {
> /* Host can handle any s/g split between our header and packet data
> */
> bool any_header_sg;
>
> + /* Packet virtio header size */
> + u8 hdr_len;
> +
> /* Active statistics */
> struct virtnet_stats __percpu *stats;
>
> @@ -139,21 +142,14 @@ struct virtnet_info {
> struct notifier_block nb;
> };
>
> -struct skb_vnet_hdr {
> - union {
> - struct virtio_net_hdr hdr;
> - struct virtio_net_hdr_mrg_rxbuf mhdr;
> - };
> -};
> -
> struct padded_vnet_hdr {
> - struct virtio_net_hdr hdr;
> + struct virtio_net_hdr_mrg_rxbuf hdr;
> /*
> - * virtio_net_hdr should be in a separated sg buffer because of a
> - * QEMU bug, and data sg buffer shares same page with this header
> sg.
> - * This padding makes next sg 16 byte aligned after virtio_net_hdr.
> + * hdr is in a separate sg buffer, and data sg buffer shares same
> page
> + * with this header sg. This padding makes next sg 16 byte aligned
> + * after the header.
> */
> - char padding[6];
> + char padding[4];
> };
>
> /* Converting between virtqueue no. and kernel tx/rx queue no.
> @@ -179,9 +175,9 @@ static int rxq2vq(int rxq)
> return rxq * 2;
> }
>
> -static inline struct skb_vnet_hdr *skb_vnet_hdr(struct sk_buff *skb)
> +static inline struct virtio_net_hdr_mrg_rxbuf *skb_vnet_hdr(struct
> sk_buff *skb)
> {
> - return (struct skb_vnet_hdr *)skb->cb;
> + return (struct virtio_net_hdr_mrg_rxbuf *)skb->cb;
> }
>
> /*
> @@ -247,7 +243,7 @@ static struct sk_buff *page_to_skb(struct
> virtnet_info *vi,
> unsigned int len, unsigned int truesize)
> {
> struct sk_buff *skb;
> - struct skb_vnet_hdr *hdr;
> + struct virtio_net_hdr_mrg_rxbuf *hdr;
> unsigned int copy, hdr_len, hdr_padded_len;
> char *p;
>
> @@ -260,13 +256,11 @@ static struct sk_buff *page_to_skb(struct
> virtnet_info *vi,
>
> hdr = skb_vnet_hdr(skb);
>
> - if (vi->mergeable_rx_bufs) {
> - hdr_len = sizeof hdr->mhdr;
> - hdr_padded_len = sizeof hdr->mhdr;
> - } else {
> - hdr_len = sizeof hdr->hdr;
> + hdr_len = vi->hdr_len;
> + if (vi->mergeable_rx_bufs)
> + hdr_padded_len = sizeof *hdr;
> + else
> hdr_padded_len = sizeof(struct padded_vnet_hdr);
> - }
>
> memcpy(hdr, p, hdr_len);
>
> @@ -317,11 +311,11 @@ static struct sk_buff *page_to_skb(struct
> virtnet_info *vi,
> return skb;
> }
>
> -static struct sk_buff *receive_small(void *buf, unsigned int len)
> +static struct sk_buff *receive_small(struct virtnet_info *vi, void
> *buf, unsigned int len)
> {
> struct sk_buff * skb = buf;
>
> - len -= sizeof(struct virtio_net_hdr);
> + len -= vi->hdr_len;
> skb_trim(skb, len);
>
> return skb;
> @@ -354,8 +348,8 @@ static struct sk_buff *receive_mergeable(struct
> net_device *dev,
> unsigned int len)
> {
> void *buf = mergeable_ctx_to_buf_address(ctx);
> - struct skb_vnet_hdr *hdr = buf;
> - u16 num_buf = virtio16_to_cpu(rq->vq->vdev, hdr->mhdr.num_buffers);
> + struct virtio_net_hdr_mrg_rxbuf *hdr = buf;
> + u16 num_buf = virtio16_to_cpu(vi->vdev, hdr->num_buffers);
> struct page *page = virt_to_head_page(buf);
> int offset = buf - page_address(page);
> unsigned int truesize = max(len,
> mergeable_ctx_to_buf_truesize(ctx));
> @@ -373,8 +367,8 @@ static struct sk_buff *receive_mergeable(struct
> net_device *dev,
> if (unlikely(!ctx)) {
> pr_debug("%s: rx error: %d buffers out of %d missing\n",
> dev->name, num_buf,
> - virtio16_to_cpu(rq->vq->vdev,
> - hdr->mhdr.num_buffers));
> + virtio16_to_cpu(vi->vdev,
> + hdr->num_buffers));
> dev->stats.rx_length_errors++;
> goto err_buf;
> }
> @@ -441,7 +435,7 @@ static void receive_buf(struct virtnet_info *vi,
> struct receive_queue *rq,
> struct net_device *dev = vi->dev;
> struct virtnet_stats *stats = this_cpu_ptr(vi->stats);
> struct sk_buff *skb;
> - struct skb_vnet_hdr *hdr;
> + struct virtio_net_hdr_mrg_rxbuf *hdr;
>
> if (unlikely(len < sizeof(struct virtio_net_hdr) + ETH_HLEN)) {
> pr_debug("%s: short packet %i\n", dev->name, len);
> @@ -463,7 +457,7 @@ static void receive_buf(struct virtnet_info *vi,
> struct receive_queue *rq,
> else if (vi->big_packets)
> skb = receive_big(dev, vi, rq, buf, len);
> else
> - skb = receive_small(buf, len);
> + skb = receive_small(vi, buf, len);
>
> if (unlikely(!skb))
> return;
> @@ -545,7 +539,7 @@ static int add_recvbuf_small(struct virtnet_info
> *vi, struct receive_queue *rq,
> gfp_t gfp)
> {
> struct sk_buff *skb;
> - struct skb_vnet_hdr *hdr;
> + struct virtio_net_hdr_mrg_rxbuf *hdr;
> int err;
>
> skb = __netdev_alloc_skb_ip_align(vi->dev, GOOD_PACKET_LEN, gfp);
> @@ -556,7 +550,7 @@ static int add_recvbuf_small(struct virtnet_info
> *vi, struct receive_queue *rq,
>
> hdr = skb_vnet_hdr(skb);
> sg_init_table(rq->sg, MAX_SKB_FRAGS + 2);
> - sg_set_buf(rq->sg, &hdr->hdr, sizeof hdr->hdr);
> + sg_set_buf(rq->sg, hdr, vi->hdr_len);
> skb_to_sgvec(skb, rq->sg + 1, 0, skb->len);
>
> err = virtqueue_add_inbuf(rq->vq, rq->sg, 2, skb, gfp);
> @@ -566,7 +560,8 @@ static int add_recvbuf_small(struct virtnet_info
> *vi, struct receive_queue *rq,
> return err;
> }
>
> -static int add_recvbuf_big(struct receive_queue *rq, gfp_t gfp)
> +static int add_recvbuf_big(struct virtnet_info *vi, struct
> receive_queue *rq,
> + gfp_t gfp)
> {
> struct page *first, *list = NULL;
> char *p;
> @@ -597,8 +592,8 @@ static int add_recvbuf_big(struct receive_queue
> *rq, gfp_t gfp)
> p = page_address(first);
>
> /* rq->sg[0], rq->sg[1] share the same page */
> - /* a separated rq->sg[0] for virtio_net_hdr only due to QEMU bug */
> - sg_set_buf(&rq->sg[0], p, sizeof(struct virtio_net_hdr));
> + /* a separated rq->sg[0] for header - required in case
> !any_header_sg */
> + sg_set_buf(&rq->sg[0], p, vi->hdr_len);
>
> /* rq->sg[1] for data packet, from offset */
> offset = sizeof(struct padded_vnet_hdr);
> @@ -677,7 +672,7 @@ static bool try_fill_recv(struct virtnet_info
> *vi, struct receive_queue *rq,
> if (vi->mergeable_rx_bufs)
> err = add_recvbuf_mergeable(rq, gfp);
> else if (vi->big_packets)
> - err = add_recvbuf_big(rq, gfp);
> + err = add_recvbuf_big(vi, rq, gfp);
> else
> err = add_recvbuf_small(vi, rq, gfp);
>
> @@ -857,18 +852,14 @@ static void free_old_xmit_skbs(struct
> send_queue *sq)
>
> static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
> {
> - struct skb_vnet_hdr *hdr;
> + struct virtio_net_hdr_mrg_rxbuf *hdr;
> const unsigned char *dest = ((struct ethhdr *)skb->data)->h_dest;
> struct virtnet_info *vi = sq->vq->vdev->priv;
> unsigned num_sg;
> - unsigned hdr_len;
> + unsigned hdr_len = vi->hdr_len;
> bool can_push;
>
> pr_debug("%s: xmit %p %pM\n", vi->dev->name, skb, dest);
> - if (vi->mergeable_rx_bufs)
> - hdr_len = sizeof hdr->mhdr;
> - else
> - hdr_len = sizeof hdr->hdr;
>
> can_push = vi->any_header_sg &&
> !((unsigned long)skb->data & (__alignof__(*hdr) - 1)) &&
> @@ -876,7 +867,7 @@ static int xmit_skb(struct send_queue *sq, struct
> sk_buff *skb)
> /* Even if we can, don't push here yet as this would skew
> * csum_start offset below. */
> if (can_push)
> - hdr = (struct skb_vnet_hdr *)(skb->data - hdr_len);
> + hdr = (struct virtio_net_hdr_mrg_rxbuf *)(skb->data - hdr_len);
> else
> hdr = skb_vnet_hdr(skb);
>
> @@ -909,7 +900,7 @@ static int xmit_skb(struct send_queue *sq, struct
> sk_buff *skb)
> }
>
> if (vi->mergeable_rx_bufs)
> - hdr->mhdr.num_buffers = 0;
> + hdr->num_buffers = 0;
>
> sg_init_table(sq->sg, MAX_SKB_FRAGS + 2);
> if (can_push) {
> @@ -1814,18 +1805,19 @@ static int virtnet_probe(struct virtio_device
> *vdev)
> if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF))
> vi->mergeable_rx_bufs = true;
>
> + if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF))
> + vi->hdr_len = sizeof(struct virtio_net_hdr_mrg_rxbuf);
> + else
> + vi->hdr_len = sizeof(struct virtio_net_hdr);
> +
> if (virtio_has_feature(vdev, VIRTIO_F_ANY_LAYOUT))
> vi->any_header_sg = true;
>
> if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
> vi->has_cvq = true;
>
> - if (vi->any_header_sg) {
> - if (vi->mergeable_rx_bufs)
> - dev->needed_headroom = sizeof(struct virtio_net_hdr_mrg_rxbuf);
> - else
> - dev->needed_headroom = sizeof(struct virtio_net_hdr);
> - }
> + if (vi->any_header_sg)
> + dev->needed_headroom = vi->hdr_len;
>
> /* Use single tx/rx queue pair as default */
> vi->curr_queue_pairs = 1;
> --
> MST
Reviewed-by: Jason Wang <jasowang@redhat.com>
^ permalink raw reply
* Re: [PATCH v6 41/46] macvtap: TUN_VNET_HDR support
From: Jason Wang @ 2014-11-28 8:24 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, David Miller, cornelia.huck, rusty, nab, pbonzini,
thuth, dahi, Vlad Yasevich, Zhi Yong Wu, Tom Herbert,
Ben Hutchings, netdev
In-Reply-To: <1417118789-18231-42-git-send-email-mst@redhat.com>
On Fri, Nov 28, 2014 at 4:11 AM, Michael S. Tsirkin <mst@redhat.com>
wrote:
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/net/macvtap.c | 68
> ++++++++++++++++++++++++++++++++-------------------
> 1 file changed, 43 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> index 880cc09..af90ab5 100644
> --- a/drivers/net/macvtap.c
> +++ b/drivers/net/macvtap.c
> @@ -45,6 +45,18 @@ struct macvtap_queue {
> struct list_head next;
> };
>
> +#define MACVTAP_FEATURES (IFF_VNET_HDR | IFF_VNET_LE |
> IFF_MULTI_QUEUE)
> +
> +static inline u16 macvtap16_to_cpu(struct macvtap_queue *q,
> __virtio16 val)
> +{
> + return __virtio16_to_cpu(q->flags & IFF_VNET_LE, val);
> +}
> +
> +static inline __virtio16 cpu_to_macvtap16(struct macvtap_queue *q,
> u16 val)
> +{
> + return __cpu_to_virtio16(q->flags & IFF_VNET_LE, val);
> +}
> +
> static struct proto macvtap_proto = {
> .name = "macvtap",
> .owner = THIS_MODULE,
> @@ -557,7 +569,8 @@ static inline struct sk_buff
> *macvtap_alloc_skb(struct sock *sk, size_t prepad,
> * macvtap_skb_from_vnet_hdr and macvtap_skb_to_vnet_hdr should
> * be shared with the tun/tap driver.
> */
> -static int macvtap_skb_from_vnet_hdr(struct sk_buff *skb,
> +static int macvtap_skb_from_vnet_hdr(struct macvtap_queue *q,
> + struct sk_buff *skb,
> struct virtio_net_hdr *vnet_hdr)
> {
> unsigned short gso_type = 0;
> @@ -588,13 +601,13 @@ static int macvtap_skb_from_vnet_hdr(struct
> sk_buff *skb,
> }
>
> if (vnet_hdr->flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) {
> - if (!skb_partial_csum_set(skb, vnet_hdr->csum_start,
> - vnet_hdr->csum_offset))
> + if (!skb_partial_csum_set(skb, macvtap16_to_cpu(q,
> vnet_hdr->csum_start),
> + macvtap16_to_cpu(q, vnet_hdr->csum_offset)))
> return -EINVAL;
> }
>
> if (vnet_hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) {
> - skb_shinfo(skb)->gso_size = vnet_hdr->gso_size;
> + skb_shinfo(skb)->gso_size = macvtap16_to_cpu(q,
> vnet_hdr->gso_size);
> skb_shinfo(skb)->gso_type = gso_type;
>
> /* Header must be checked, and gso_segs computed. */
> @@ -604,8 +617,9 @@ static int macvtap_skb_from_vnet_hdr(struct
> sk_buff *skb,
> return 0;
> }
>
> -static void macvtap_skb_to_vnet_hdr(const struct sk_buff *skb,
> - struct virtio_net_hdr *vnet_hdr)
> +static void macvtap_skb_to_vnet_hdr(struct macvtap_queue *q,
> + const struct sk_buff *skb,
> + struct virtio_net_hdr *vnet_hdr)
> {
> memset(vnet_hdr, 0, sizeof(*vnet_hdr));
>
> @@ -613,8 +627,8 @@ static void macvtap_skb_to_vnet_hdr(const struct
> sk_buff *skb,
> struct skb_shared_info *sinfo = skb_shinfo(skb);
>
> /* This is a hint as to how much should be linear. */
> - vnet_hdr->hdr_len = skb_headlen(skb);
> - vnet_hdr->gso_size = sinfo->gso_size;
> + vnet_hdr->hdr_len = cpu_to_macvtap16(q, skb_headlen(skb));
> + vnet_hdr->gso_size = cpu_to_macvtap16(q, sinfo->gso_size);
> if (sinfo->gso_type & SKB_GSO_TCPV4)
> vnet_hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
> else if (sinfo->gso_type & SKB_GSO_TCPV6)
> @@ -628,10 +642,13 @@ static void macvtap_skb_to_vnet_hdr(const
> struct sk_buff *skb,
>
> if (skb->ip_summed == CHECKSUM_PARTIAL) {
> vnet_hdr->flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;
> - vnet_hdr->csum_start = skb_checksum_start_offset(skb);
> if (vlan_tx_tag_present(skb))
> - vnet_hdr->csum_start += VLAN_HLEN;
> - vnet_hdr->csum_offset = skb->csum_offset;
> + vnet_hdr->csum_start = cpu_to_macvtap16(q,
> + skb_checksum_start_offset(skb) + VLAN_HLEN);
> + else
> + vnet_hdr->csum_start = cpu_to_macvtap16(q,
> + skb_checksum_start_offset(skb));
> + vnet_hdr->csum_offset = cpu_to_macvtap16(q, skb->csum_offset);
> } else if (skb->ip_summed == CHECKSUM_UNNECESSARY) {
> vnet_hdr->flags = VIRTIO_NET_HDR_F_DATA_VALID;
> } /* else everything is zero */
> @@ -666,12 +683,14 @@ static ssize_t macvtap_get_user(struct
> macvtap_queue *q, struct msghdr *m,
> if (err < 0)
> goto err;
> if ((vnet_hdr.flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) &&
> - vnet_hdr.csum_start + vnet_hdr.csum_offset + 2 >
> - vnet_hdr.hdr_len)
> - vnet_hdr.hdr_len = vnet_hdr.csum_start +
> - vnet_hdr.csum_offset + 2;
> + macvtap16_to_cpu(q, vnet_hdr.csum_start) +
> + macvtap16_to_cpu(q, vnet_hdr.csum_offset) + 2 >
> + macvtap16_to_cpu(q, vnet_hdr.hdr_len))
> + vnet_hdr.hdr_len = cpu_to_macvtap16(q,
> + macvtap16_to_cpu(q, vnet_hdr.csum_start) +
> + macvtap16_to_cpu(q, vnet_hdr.csum_offset) + 2);
> err = -EINVAL;
> - if (vnet_hdr.hdr_len > len)
> + if (macvtap16_to_cpu(q, vnet_hdr.hdr_len) > len)
> goto err;
> }
>
> @@ -684,7 +703,8 @@ static ssize_t macvtap_get_user(struct
> macvtap_queue *q, struct msghdr *m,
> goto err;
>
> if (m && m->msg_control && sock_flag(&q->sk, SOCK_ZEROCOPY)) {
> - copylen = vnet_hdr.hdr_len ? vnet_hdr.hdr_len : GOODCOPY_LEN;
> + copylen = vnet_hdr.hdr_len ?
> + macvtap16_to_cpu(q, vnet_hdr.hdr_len) : GOODCOPY_LEN;
> if (copylen > good_linear)
> copylen = good_linear;
> linear = copylen;
> @@ -695,10 +715,10 @@ static ssize_t macvtap_get_user(struct
> macvtap_queue *q, struct msghdr *m,
>
> if (!zerocopy) {
> copylen = len;
> - if (vnet_hdr.hdr_len > good_linear)
> + if (macvtap16_to_cpu(q, vnet_hdr.hdr_len) > good_linear)
> linear = good_linear;
> else
> - linear = vnet_hdr.hdr_len;
> + linear = macvtap16_to_cpu(q, vnet_hdr.hdr_len);
> }
>
> skb = macvtap_alloc_skb(&q->sk, NET_IP_ALIGN, copylen,
> @@ -725,7 +745,7 @@ static ssize_t macvtap_get_user(struct
> macvtap_queue *q, struct msghdr *m,
> skb->protocol = eth_hdr(skb)->h_proto;
>
> if (vnet_hdr_len) {
> - err = macvtap_skb_from_vnet_hdr(skb, &vnet_hdr);
> + err = macvtap_skb_from_vnet_hdr(q, skb, &vnet_hdr);
> if (err)
> goto err_kfree;
> }
> @@ -791,7 +811,7 @@ static ssize_t macvtap_put_user(struct
> macvtap_queue *q,
> if ((len -= vnet_hdr_len) < 0)
> return -EINVAL;
>
> - macvtap_skb_to_vnet_hdr(skb, &vnet_hdr);
> + macvtap_skb_to_vnet_hdr(q, skb, &vnet_hdr);
>
> if (memcpy_toiovecend(iv, (void *)&vnet_hdr, 0, sizeof(vnet_hdr)))
> return -EFAULT;
> @@ -1003,8 +1023,7 @@ static long macvtap_ioctl(struct file *file,
> unsigned int cmd,
> return -EFAULT;
>
> ret = 0;
> - if ((u & ~(IFF_VNET_HDR | IFF_MULTI_QUEUE)) !=
> - (IFF_NO_PI | IFF_TAP))
> + if ((u & ~MACVTAP_FEATURES) != (IFF_NO_PI | IFF_TAP))
> ret = -EINVAL;
> else
> q->flags = u;
> @@ -1036,8 +1055,7 @@ static long macvtap_ioctl(struct file *file,
> unsigned int cmd,
> return ret;
>
> case TUNGETFEATURES:
> - if (put_user(IFF_TAP | IFF_NO_PI | IFF_VNET_HDR |
> - IFF_MULTI_QUEUE, up))
> + if (put_user(IFF_TAP | IFF_NO_PI | MACVTAP_FEATURES, up))
> return -EFAULT;
> return 0;
>
> --
> MST
Reviewed-by: Jason Wang <jasowang@redhat.com>
btw, title should be macvtap: IFF_VNET_LE support
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox