* Re: [patch net-next v3 04/17] net: introduce generic switch devices support
From: Jamal Hadi Salim @ 2014-11-28 13:13 UTC (permalink / raw)
To: Jiri Pirko
Cc: Thomas Graf, Scott Feldman, Netdev, David S. Miller,
nhorman@tuxdriver.com, Andy Gospodarek, 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, Florian Fainelli, Roopa Prabhu,
John Linville
In-Reply-To: <20141127135050.GD1877@nanopsycho.orion>
On 11/27/14 08:50, Jiri Pirko wrote:
> $ git grep offload net
> Wouldn't it be confusing to add this another different "offload". That's
> just confusing.
>
> I still like "switch" the best. If it passes packets around, it's a
> "switch", +-. Everybody understand what's going on if you use "switch".
> If you use "offload", everybody is confused...
>
Those are all *legitimate offloads* ;->
The macvlan one looks a little creepy. Perhaps we could eventually
merge all that stuff together with this effort.
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v4 14/21] bridge: add brport flags to dflt bridge_getlink
From: Jamal Hadi Salim @ 2014-11-28 13:07 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, Florian Fainelli, Roopa Prabhu,
John Linville
In-Reply-To: <CAE4R7bBqAg0CoEcz0s6MKnCH60YEk3EMDD875H_p4GtRhGMGUQ@mail.gmail.com>
On 11/27/14 15:46, Scott Feldman wrote:
> On Thu, Nov 27, 2014 at 3:17 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>
> For RTM_GETLINK, rtnl_bridge_getlink() calls ndo_bridge_getlink twice
> for each dev, once on bridge and second time on dev. Each call adds
> an RTM_NEWLINK to skb. For the ndo_bridge_getlink() call to bridge,
> the MASTER port flags are filled in using br_port_fill_attr(). For
> the second ndo_bridge_getlink() call to dev, the port driver calls
> ndo_dflt_bridge_getlink() which fills in the SELF port flags. Before
> this patch, ndo_dflt_bridge_getlink() was only filling in hwmode.
>
> Whew, in any case, I think you'll agree this code needs a refactoring
> down the road. This change is just the bare minimum building on
> what's there to get SELF port flags up to user-space. A refactoring
> effort should get the port drivers out of parsing/filling netlink msg
> and leave that to the core code in rtnetlink.c. That way we can have
> one place for policy checks and one place for fill. I think this
> refactoring effort should be left out in this patch series, otherwise
> this is going to drag on into the next year.
>
I am fine with that. At minimal br_port_fill_attr() is reusable.
There's a lot of stuff i wish would be "fixed" - one is clearly
not abusing a u8 just to send one bit to the kernel. You just
added one more horn of that sort with the sync learning.
I wish i had time to clean it up. In any case:
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* [PATCH] cxgb4: Fill in supported link mode for SFP modules
From: Hariprasad Shenai @ 2014-11-28 13:05 UTC (permalink / raw)
To: netdev; +Cc: davem, leedom, nirranjan, Hariprasad Shenai
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 605eaab..279275d 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -2362,9 +2362,13 @@ static unsigned int from_fw_linkcaps(unsigned int type, unsigned int caps)
SUPPORTED_10000baseKR_Full | SUPPORTED_1000baseKX_Full |
SUPPORTED_10000baseKX4_Full;
else if (type == FW_PORT_TYPE_FIBER_XFI ||
- type == FW_PORT_TYPE_FIBER_XAUI || type == FW_PORT_TYPE_SFP)
+ type == FW_PORT_TYPE_FIBER_XAUI || type == FW_PORT_TYPE_SFP) {
v |= SUPPORTED_FIBRE;
- else if (type == FW_PORT_TYPE_BP40_BA)
+ if (caps & FW_PORT_CAP_SPEED_1G)
+ v |= SUPPORTED_1000baseT_Full;
+ if (caps & FW_PORT_CAP_SPEED_10G)
+ v |= SUPPORTED_10000baseT_Full;
+ } else if (type == FW_PORT_TYPE_BP40_BA)
v |= SUPPORTED_40000baseSR4_Full;
if (caps & FW_PORT_CAP_ANEG)
--
1.7.1
^ permalink raw reply related
* Re: [patch net-next v3 02/17] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
From: Jamal Hadi Salim @ 2014-11-28 12:57 UTC (permalink / raw)
To: Jiri Pirko, Scott Feldman
Cc: John Fastabend, 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, Roopa Prabhu, John Linville,
"jasowang@redhat.com" <jasow
In-Reply-To: <20141127215529.GA17784@nanopsycho.orion>
On 11/27/14 16:55, Jiri Pirko wrote:
> Thu, Nov 27, 2014 at 09:59:37PM CET, sfeldma@gmail.com wrote:
>> Ya right now the driver just doesn't call br_fdb_external_learn_add()
>> if LEARNING_SYNC is not set. It's a port driver setting so it seems
>> fine to handle it in the port driver. You could move the check up to
>> br_fdb_external_learn_add(), but then you have an extra call every 1s
>> for each fdb entry being refreshed. (1s or whatever the refresh
>> frequency is). Easier to avoid this overhead and make the decision at
>> the source.
>
> I have been thinking about moving the check into bridge code, it to make
> it there as well as in drivers. This is easily changeable on demenad
> later though, so I left this for now.
>
It seems more comfortable to move to the core if you are doing polling
with timers... i.e you kick it per-offload via some timer. The arming
being done by the setting of LEARNING_SYNC
There are cases where all this is done via interrupts. i.e the hardware
will issue an interrupt only then do you poll..
Maybe Scott's approach is the correct one. I am indifferent to be
honest, these are some of those things that can be easily refactored
as more hardware shows up.
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v4 00/21] introduce rocker switch driver with hardware accelerated datapath api - phase 1: bridge fdb offload
From: Jiri Pirko @ 2014-11-28 12:07 UTC (permalink / raw)
To: Scott Feldman
Cc: 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, Roopa Prabhu, John Linville
In-Reply-To: <CAE4R7bDNbyfxx+XExmej8-p=E3X4cHc+Sr75S=aO67XMYcmU8g@mail.gmail.com>
Fri, Nov 28, 2014 at 12:59:17PM CET, sfeldma@gmail.com wrote:
>Thanks Jiri for coordinating this effort. It looks like we're close
>to convergence on this first patch set. I sifted thru review comments
>and compiled a list of items for follow-on work. I hope it's OK to
>use etherpad for this:
>
>https://etherpad.wikimedia.org/p/netdev-swdev-todo
>
>Feel free to edit as needed and claim an item if you intend to work on
>it. Don't turn the etherpad into a discussion board...try to keep it
>as list of work items. I don't think any of these items should hold
>up current patch set.
Agree. Good idea putting the todo list on etherpad.
So I will post v5 just with the whitespace issue fixed (pointed out by
Sergei Shtylyov).
Thanks.
>
>-scott
>
>On Thu, Nov 27, 2014 at 2:40 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Hi all.
>>
>> This patchset is just the first phase of switch and switch-ish device
>> support api in kernel. Note that the api will extend.
>>
>> So what this patchset includes:
>> - introduce switchdev api skeleton for implementing switch drivers
>> - introduce rocker switch driver which implements switchdev api fdb and
>> bridge set/get link ndos
>>
>> As to the discussion if there is need to have specific class of device
>> representing the switch itself, so far we found no need to introduce that.
>> But we are generally ok with the idea and when the time comes and it will
>> be needed, it can be easily introduced without any disturbance.
>>
>> This patchset introduces switch id export through rtnetlink and sysfs,
>> which is similar to what we have for port id in SR-IOV. I will send iproute2
>> patchset for showing the switch id for port netdevs once this is applied.
>> This applies also for the PF_BRIDGE and fdb iproute2 patches.
>>
>> iproute2 patches are now available here:
>> https://github.com/jpirko/iproute2-rocker
>>
>> For detailed description and version history, please see individual patches.
>>
>> In v4 I reordered the patches leaving rocker patches on the end of the patchset.
>>
>> Jiri Pirko (10):
>> bridge: rename fdb_*_hw to fdb_*_hw_addr to avoid confusion
>> neigh: sort Neighbor Cache Entry Flags
>> bridge: convert flags in fbd entry into bitfields
>> net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
>> net: rename netdev_phys_port_id to more generic name
>> net: introduce generic switch devices support
>> rtnl: expose physical switch id for particular device
>> net-sysfs: expose physical switch id for particular device
>> rocker: introduce rocker switch driver
>> rocker: implement ndo_fdb_dump
>>
>> Scott Feldman (9):
>> bridge: call netdev_sw_port_stp_update when bridge port STP status
>> changes
>> bridge: add API to notify bridge driver of learned FBD on offloaded
>> device
>> bridge: move private brport flags to if_bridge.h so port drivers can
>> use flags
>> bridge: add new brport flag LEARNING_SYNC
>> bridge: add new hwmode swdev
>> bridge: add brport flags to dflt bridge_getlink
>> rocker: implement rocker ofdpa flow table manipulation
>> rocker: implement L2 bridge offloading
>> rocker: add ndo_bridge_setlink/getlink support for learning policy
>>
>> Thomas Graf (2):
>> rocker: Add proper validation of Netlink attributes
>> rocker: Use logical operators on booleans
>>
>> Documentation/ABI/testing/sysfs-class-net | 8 +
>> Documentation/networking/switchdev.txt | 59 +
>> MAINTAINERS | 14 +
>> drivers/net/ethernet/Kconfig | 1 +
>> drivers/net/ethernet/Makefile | 1 +
>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +-
>> drivers/net/ethernet/emulex/benet/be_main.c | 3 +-
>> drivers/net/ethernet/intel/i40e/i40e_main.c | 4 +-
>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 +-
>> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
>> drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 11 +-
>> drivers/net/ethernet/rocker/Kconfig | 27 +
>> drivers/net/ethernet/rocker/Makefile | 5 +
>> drivers/net/ethernet/rocker/rocker.c | 4374 ++++++++++++++++++++++
>> drivers/net/ethernet/rocker/rocker.h | 428 +++
>> drivers/net/macvlan.c | 4 +-
>> drivers/net/vxlan.c | 4 +-
>> include/linux/if_bridge.h | 31 +
>> include/linux/netdevice.h | 39 +-
>> include/linux/rtnetlink.h | 9 +-
>> include/net/switchdev.h | 37 +
>> include/uapi/linux/if_bridge.h | 1 +
>> include/uapi/linux/if_link.h | 2 +
>> include/uapi/linux/neighbour.h | 6 +-
>> net/Kconfig | 1 +
>> net/Makefile | 3 +
>> net/bridge/br_fdb.c | 144 +-
>> net/bridge/br_private.h | 21 +-
>> net/bridge/br_stp.c | 7 +
>> net/core/dev.c | 2 +-
>> net/core/net-sysfs.c | 26 +-
>> net/core/rtnetlink.c | 119 +-
>> net/switchdev/Kconfig | 13 +
>> net/switchdev/Makefile | 5 +
>> net/switchdev/switchdev.c | 52 +
>> 35 files changed, 5366 insertions(+), 105 deletions(-)
>> create mode 100644 Documentation/networking/switchdev.txt
>> create mode 100644 drivers/net/ethernet/rocker/Kconfig
>> create mode 100644 drivers/net/ethernet/rocker/Makefile
>> create mode 100644 drivers/net/ethernet/rocker/rocker.c
>> create mode 100644 drivers/net/ethernet/rocker/rocker.h
>> create mode 100644 include/net/switchdev.h
>> create mode 100644 net/switchdev/Kconfig
>> create mode 100644 net/switchdev/Makefile
>> create mode 100644 net/switchdev/switchdev.c
>>
>> --
>> 1.9.3
>>
^ permalink raw reply
* Re: [patch net-next v4 00/21] introduce rocker switch driver with hardware accelerated datapath api - phase 1: bridge fdb offload
From: Scott Feldman @ 2014-11-28 11:59 UTC (permalink / raw)
To: Jiri Pirko
Cc: 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, Roopa Prabhu, John Linville
In-Reply-To: <1417084826-9875-1-git-send-email-jiri@resnulli.us>
Thanks Jiri for coordinating this effort. It looks like we're close
to convergence on this first patch set. I sifted thru review comments
and compiled a list of items for follow-on work. I hope it's OK to
use etherpad for this:
https://etherpad.wikimedia.org/p/netdev-swdev-todo
Feel free to edit as needed and claim an item if you intend to work on
it. Don't turn the etherpad into a discussion board...try to keep it
as list of work items. I don't think any of these items should hold
up current patch set.
-scott
On Thu, Nov 27, 2014 at 2:40 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> Hi all.
>
> This patchset is just the first phase of switch and switch-ish device
> support api in kernel. Note that the api will extend.
>
> So what this patchset includes:
> - introduce switchdev api skeleton for implementing switch drivers
> - introduce rocker switch driver which implements switchdev api fdb and
> bridge set/get link ndos
>
> As to the discussion if there is need to have specific class of device
> representing the switch itself, so far we found no need to introduce that.
> But we are generally ok with the idea and when the time comes and it will
> be needed, it can be easily introduced without any disturbance.
>
> This patchset introduces switch id export through rtnetlink and sysfs,
> which is similar to what we have for port id in SR-IOV. I will send iproute2
> patchset for showing the switch id for port netdevs once this is applied.
> This applies also for the PF_BRIDGE and fdb iproute2 patches.
>
> iproute2 patches are now available here:
> https://github.com/jpirko/iproute2-rocker
>
> For detailed description and version history, please see individual patches.
>
> In v4 I reordered the patches leaving rocker patches on the end of the patchset.
>
> Jiri Pirko (10):
> bridge: rename fdb_*_hw to fdb_*_hw_addr to avoid confusion
> neigh: sort Neighbor Cache Entry Flags
> bridge: convert flags in fbd entry into bitfields
> net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
> net: rename netdev_phys_port_id to more generic name
> net: introduce generic switch devices support
> rtnl: expose physical switch id for particular device
> net-sysfs: expose physical switch id for particular device
> rocker: introduce rocker switch driver
> rocker: implement ndo_fdb_dump
>
> Scott Feldman (9):
> bridge: call netdev_sw_port_stp_update when bridge port STP status
> changes
> bridge: add API to notify bridge driver of learned FBD on offloaded
> device
> bridge: move private brport flags to if_bridge.h so port drivers can
> use flags
> bridge: add new brport flag LEARNING_SYNC
> bridge: add new hwmode swdev
> bridge: add brport flags to dflt bridge_getlink
> rocker: implement rocker ofdpa flow table manipulation
> rocker: implement L2 bridge offloading
> rocker: add ndo_bridge_setlink/getlink support for learning policy
>
> Thomas Graf (2):
> rocker: Add proper validation of Netlink attributes
> rocker: Use logical operators on booleans
>
> Documentation/ABI/testing/sysfs-class-net | 8 +
> Documentation/networking/switchdev.txt | 59 +
> MAINTAINERS | 14 +
> drivers/net/ethernet/Kconfig | 1 +
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +-
> drivers/net/ethernet/emulex/benet/be_main.c | 3 +-
> drivers/net/ethernet/intel/i40e/i40e_main.c | 4 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 +-
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 11 +-
> drivers/net/ethernet/rocker/Kconfig | 27 +
> drivers/net/ethernet/rocker/Makefile | 5 +
> drivers/net/ethernet/rocker/rocker.c | 4374 ++++++++++++++++++++++
> drivers/net/ethernet/rocker/rocker.h | 428 +++
> drivers/net/macvlan.c | 4 +-
> drivers/net/vxlan.c | 4 +-
> include/linux/if_bridge.h | 31 +
> include/linux/netdevice.h | 39 +-
> include/linux/rtnetlink.h | 9 +-
> include/net/switchdev.h | 37 +
> include/uapi/linux/if_bridge.h | 1 +
> include/uapi/linux/if_link.h | 2 +
> include/uapi/linux/neighbour.h | 6 +-
> net/Kconfig | 1 +
> net/Makefile | 3 +
> net/bridge/br_fdb.c | 144 +-
> net/bridge/br_private.h | 21 +-
> net/bridge/br_stp.c | 7 +
> net/core/dev.c | 2 +-
> net/core/net-sysfs.c | 26 +-
> net/core/rtnetlink.c | 119 +-
> net/switchdev/Kconfig | 13 +
> net/switchdev/Makefile | 5 +
> net/switchdev/switchdev.c | 52 +
> 35 files changed, 5366 insertions(+), 105 deletions(-)
> create mode 100644 Documentation/networking/switchdev.txt
> create mode 100644 drivers/net/ethernet/rocker/Kconfig
> create mode 100644 drivers/net/ethernet/rocker/Makefile
> create mode 100644 drivers/net/ethernet/rocker/rocker.c
> create mode 100644 drivers/net/ethernet/rocker/rocker.h
> create mode 100644 include/net/switchdev.h
> create mode 100644 net/switchdev/Kconfig
> create mode 100644 net/switchdev/Makefile
> create mode 100644 net/switchdev/switchdev.c
>
> --
> 1.9.3
>
^ permalink raw reply
* Re: [patch net-next v3 08/17] bridge: call netdev_sw_port_stp_update when bridge port STP status changes
From: Scott Feldman @ 2014-11-28 10:51 UTC (permalink / raw)
To: Roopa Prabhu
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: <547848D8.1060203@cumulusnetworks.com>
On Fri, Nov 28, 2014 at 2:05 AM, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
> On 11/25/14, 5:35 PM, Scott Feldman wrote:
>>
>> 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.
Sure, call it port state but it takes on BR_STATE_xxx values which
just so happen to correspond exactly to STP states.
> 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.
Well it does...see ndo_bridge_setlink in bridge driver, br_setport
where IFLA_BRPORT_STATE is handled...it calls br_set_port_state(),
which calls into the swdev port driver. That's for the case where
user or external processing is setting STP state. For the case where
the bridge itself is managing the STP state, the bridge will make the
same br_set_port_state() call to adjust the port state.
> 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 iproute2] ip xfrm: support 64bit kernel and 32bit userspace
From: David Laight @ 2014-11-28 10:47 UTC (permalink / raw)
To: 'roy.qing.li@gmail.com', netdev@vger.kernel.org
In-Reply-To: <1417157936-5522-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
> From: Li RongQing <roy.qing.li@gmail.com>
>
> The size of struct xfrm_userpolicy_info is 168 bytes for 64bit kernel, and
> 164 bytes for 32bit userspace because of the different alignment. and lead
> to "ip xfrm" be unable to work.
>
> add a pad in struct xfrm_userpolicy_info, and enable it by set
> KERNEL_64_USERSPACE_32 to y
...
> diff --git a/include/linux/xfrm.h b/include/linux/xfrm.h
> index fa2ecb2..009510c 100644
> --- a/include/linux/xfrm.h
> +++ b/include/linux/xfrm.h
> @@ -407,6 +407,9 @@ struct xfrm_userpolicy_info {
> /* Automatically expand selector to include matching ICMP payloads. */
> #define XFRM_POLICY_ICMP 2
> __u8 share;
> +#ifdef KNL_64_US_32
> + int pad;
> +#endif
> };
You could add __attribute__((aligned(8))) to the structure to pad it on
all systems.
Or find the 64bit member and add __attribute__((aligned(4))) to that member
so that the 64bit version doesn't get padded.
That will make the field more expensive to access on systems that can't
do misaligned memory transfers.
David
^ permalink raw reply
* Re: [patch net-next v3 02/17] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
From: Scott Feldman @ 2014-11-28 10:33 UTC (permalink / raw)
To: Roopa Prabhu
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: <54784B1D.8090508@cumulusnetworks.com>
On Fri, Nov 28, 2014 at 2:14 AM, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
> 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.
Ya, I understood that from Jamal's explanation.
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-11-28 10:27 UTC (permalink / raw)
To: Bjørn Mork
Cc: Alex Strizhevsky, ShaojunMidge.Tan, Mingying.Zhu, youtux,
linux-usb, netdev, Eli.Britstein
In-Reply-To: <87ppc71xne.fsf@nemi.mork.no>
... and what do you think regarding the last arp packet Kevin shared with us
after having changed the remainder fixed value.
^ permalink raw reply
* Re: [PATCH net-next] bridge: add vlan id to mdb notifications
From: Roopa Prabhu @ 2014-11-28 10:18 UTC (permalink / raw)
To: Thomas Graf
Cc: Stephen Hemminger, vyasevich, netdev, wkok, gospo, jtoppins,
sashok, Shrijeet Mukherjee
In-Reply-To: <20141126215327.GC13786@casper.infradead.org>
On 11/26/14, 1:53 PM, Thomas Graf wrote:
> On 11/26/14 at 12:40pm, Roopa Prabhu wrote:
>> I have always wondered, if binary netlink attributes have this restriction,
>> they should be discouraged. especially when the other extensible option is
>> to add them as a separate netlink attribute.
> This is pretty much exactly the reason why attributes have been
> introduced ;-)
thanks for confirming that thomas :). Will resubmit the patch with vlan
information as a separate attribute.
^ permalink raw reply
* 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
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