* Re: [patch net-next v2 8/9] switchdev: introduce Netlink API
From: Jiri Pirko @ 2014-09-20 8:09 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Jamal Hadi Salim, netdev, davem, nhorman, andy, tgraf, dborkman,
ogerlitz, jesse, pshelar, azhou, ben, stephen, jeffrey.t.kirsher,
vyasevic, xiyou.wangcong, john.r.fastabend, edumazet, sfeldma,
f.fainelli, linville, dev, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck,
Shrijeet Mukherjee
In-Reply-To: <541CF75C.9030209@cumulusnetworks.com>
Sat, Sep 20, 2014 at 05:41:16AM CEST, roopa@cumulusnetworks.com wrote:
>On 9/19/14, 8:49 AM, Jiri Pirko wrote:
>>Fri, Sep 19, 2014 at 05:25:48PM CEST, jhs@mojatatu.com wrote:
>>>On 09/19/14 09:49, Jiri Pirko wrote:
>>>>This patch exposes switchdev API using generic Netlink.
>>>>Example userspace utility is here:
>>>>https://github.com/jpirko/switchdev
>>>>
>>>Is this just a temporary test tool? Otherwise i dont see reason
>>>for its existence (or the API that it feeds on).
>>Please read the conversation I had with Pravin and Jesse in v1 thread.
>>Long story short they like to have the api separated from ovs datapath
>>so ovs daemon can use it to directly communicate with driver. Also John
>>Fastabend requested a way to work with driver flows without using ovs ->
>>that was the original reason I created switchdev genl api.
>>
>>Regarding the "sw" tool, yes it is for testing purposes now. ovs daemon
>>will use directly switchdev genl api.
>>
>>I hope I cleared this out.
>We already have all the needed rtnetlink kernel api and userspace tools
>around it to support all
>switching asic features. ie, the rtnetlink api is the switchdev api. We can
>do l2, l3, acl's with it.
>Its unclear to me why we need another new netlink api. Which will mean none
>of the existing tools to
>create bridges etc will work on a switchdev.
No one is proposing such API. Note that what I'm trying to solve in my
patchset is FLOW world. There is only one API there, ovs genl. But the
usage of that for hw offload purposes was nacked by ovs maintainer. Plus
couple of people wanted to run the offloading independently on ovs
instance. Therefore I introduced the switchdev genl, which takes care of
that. No plan to extend it for other things you mentioned, just flows.
>Which seems like going in the direction exactly opposite to what we had
>discussed earlier.
Nope. The previous discussion ignored flows.
>
>If a non-ovs flow interface is needed from userspace, we can extend the
>existing interface to include flows.
How? You mean to extend rtnetlink? What advantage it would bring
comparing to separate genl iface?
>I don't understand why we should replace the existing rtnetlink switchdev api
>to accommodate flows.
Sorry, I do not undertand what "existing rtnetlink switchdev api" you
have on mind. Would you care to explain?
>
>Thanks,
>Roopa
>
^ permalink raw reply
* Re: [patch net-next v2 8/9] switchdev: introduce Netlink API
From: Scott Feldman @ 2014-09-20 8:10 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Jiri Pirko, Jamal Hadi Salim, netdev, davem, nhorman, andy, tgraf,
dborkman, ogerlitz, jesse, pshelar, azhou, ben, stephen,
jeffrey.t.kirsher, vyasevic, xiyou.wangcong, john.r.fastabend,
edumazet, f.fainelli, linville, dev, jasowang, ebiederm,
nicolas.dichtel, ryazanov.s.a, buytenh, aviadr, nbd,
alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, Shrijeet Mukherjee
In-Reply-To: <541CF75C.9030209@cumulusnetworks.com>
On Sep 19, 2014, at 8:41 PM, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
> On 9/19/14, 8:49 AM, Jiri Pirko wrote:
>> Fri, Sep 19, 2014 at 05:25:48PM CEST, jhs@mojatatu.com wrote:
>>> On 09/19/14 09:49, Jiri Pirko wrote:
>>>> This patch exposes switchdev API using generic Netlink.
>>>> Example userspace utility is here:
>>>> https://github.com/jpirko/switchdev
>>>>
>>> Is this just a temporary test tool? Otherwise i dont see reason
>>> for its existence (or the API that it feeds on).
>> Please read the conversation I had with Pravin and Jesse in v1 thread.
>> Long story short they like to have the api separated from ovs datapath
>> so ovs daemon can use it to directly communicate with driver. Also John
>> Fastabend requested a way to work with driver flows without using ovs ->
>> that was the original reason I created switchdev genl api.
>>
>> Regarding the "sw" tool, yes it is for testing purposes now. ovs daemon
>> will use directly switchdev genl api.
>>
>> I hope I cleared this out.
> We already have all the needed rtnetlink kernel api and userspace tools around it to support all
> switching asic features. ie, the rtnetlink api is the switchdev api. We can do l2, l3, acl's with it.
> Its unclear to me why we need another new netlink api. Which will mean none of the existing tools to
> create bridges etc will work on a switchdev.
> Which seems like going in the direction exactly opposite to what we had discussed earlier.
Existing rtnetlink isn’t available to swdev without some kind of snooping the echoes from the various kernel components (bridge, fib, etc). With swdev_flow, as Jiri has defined it, there is an additional conversion needed to bridge the gap (bad expression, I know) between rtnetlink and swdev_flow. This conversion happens in the kernel components. For example, the bridge module, still driven from userspace by existing rtnetlink, will formulate the necessary swdev_flow insert/remove calls to the swdev driver such that HW will offload the fwd path.
You have:
user -> rtnetlink -> kernel -> netlink echo -> [some process] -> [some driver] -> HW
Jiri has:
user -> rtnetlink -> kernel -> swdev_* -> swdev driver -> HW
> If a non-ovs flow interface is needed from userspace, we can extend the existing interface to include flows.
> I don't understand why we should replace the existing rtnetlink switchdev api to accommodate flows.
>
> Thanks,
> Roopa
>
-scott
^ permalink raw reply
* Re: [patch net-next v2 8/9] switchdev: introduce Netlink API
From: Jiri Pirko @ 2014-09-20 8:14 UTC (permalink / raw)
To: John Fastabend
Cc: Jamal Hadi Salim, netdev, davem, nhorman, andy, tgraf, dborkman,
ogerlitz, jesse, pshelar, azhou, ben, stephen, jeffrey.t.kirsher,
vyasevic, xiyou.wangcong, edumazet, sfeldma, f.fainelli, roopa,
linville, dev, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck
In-Reply-To: <541CAA3C.5080105@intel.com>
Sat, Sep 20, 2014 at 12:12:12AM CEST, john.r.fastabend@intel.com wrote:
>On 09/19/2014 10:57 AM, Jamal Hadi Salim wrote:
>> On 09/19/14 11:49, Jiri Pirko wrote:
>>> Fri, Sep 19, 2014 at 05:25:48PM CEST, jhs@mojatatu.com wrote:
>>
>>>> Is this just a temporary test tool? Otherwise i dont see reason
>>>> for its existence (or the API that it feeds on).
>>>
>>> Please read the conversation I had with Pravin and Jesse in v1 thread.
>>> Long story short they like to have the api separated from ovs datapath
>>> so ovs daemon can use it to directly communicate with driver. Also John
>>> Fastabend requested a way to work with driver flows without using ovs ->
>>> that was the original reason I created switchdev genl api.
>>>
>>> Regarding the "sw" tool, yes it is for testing purposes now. ovs daemon
>>> will use directly switchdev genl api.
>>>
>>> I hope I cleared this out.
>>>
>>
>> It is - thanks Jiri.
>>
>> cheers,
>> jamal
>
>Hi Jiri,
>
>I was considering a slightly different approach where the
>device would report via netlink the fields/actions it
>supported rather than creating pre-defined enums for every
>possible key.
>
>I already need to have an API to report fields/matches
>that are being supported why not have the device report
>the headers as header fields (len, offset) and the
>associated parse graph the hardware uses? Vendors should
>have this already to describe/design their real hardware.
Hmm, let me think about this a bit more. I will try to figure out how to
handle that. Sound logic though. Will try to incorporate the idea in the
patchset.
>
>As always its better to have code and when I get some
>time I'll try to write it up. Maybe its just a separate
>classifier although I don't actually want two hardware
>flow APIs.
Understood.
>
>I see you dropped the RFC tag are you proposing we include
>this now?
v11 is my bet :)
>
>.John
^ permalink raw reply
* Re: [patch net-next v2 8/9] switchdev: introduce Netlink API
From: Jiri Pirko @ 2014-09-20 8:17 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: John Fastabend, netdev, davem, nhorman, andy, tgraf, dborkman,
ogerlitz, jesse, pshelar, azhou, ben, stephen, jeffrey.t.kirsher,
vyasevic, xiyou.wangcong, edumazet, sfeldma, f.fainelli, roopa,
linville, dev, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck
In-Reply-To: <541CAB9A.3040100@mojatatu.com>
Sat, Sep 20, 2014 at 12:18:02AM CEST, jhs@mojatatu.com wrote:
>On 09/19/14 18:12, John Fastabend wrote:
>>On 09/19/2014 10:57 AM, Jamal Hadi Salim wrote:
>>>On 09/19/14 11:49, Jiri Pirko wrote:
>>>>Fri, Sep 19, 2014 at 05:25:48PM CEST, jhs@mojatatu.com wrote:
>>>
>>>>>Is this just a temporary test tool? Otherwise i dont see reason
>>>>>for its existence (or the API that it feeds on).
>>>>
>>>>Please read the conversation I had with Pravin and Jesse in v1 thread.
>>>>Long story short they like to have the api separated from ovs datapath
>>>>so ovs daemon can use it to directly communicate with driver. Also John
>>>>Fastabend requested a way to work with driver flows without using ovs ->
>>>>that was the original reason I created switchdev genl api.
>>>>
>>>>Regarding the "sw" tool, yes it is for testing purposes now. ovs daemon
>>>>will use directly switchdev genl api.
>>>>
>>>>I hope I cleared this out.
>>>>
>>>
>>>It is - thanks Jiri.
>>>
>>>cheers,
>>>jamal
>>
>>Hi Jiri,
>>
>>I was considering a slightly different approach where the
>>device would report via netlink the fields/actions it
>>supported rather than creating pre-defined enums for every
>>possible key.
>>
>>I already need to have an API to report fields/matches
>>that are being supported why not have the device report
>>the headers as header fields (len, offset) and the
>>associated parse graph the hardware uses? Vendors should
>>have this already to describe/design their real hardware.
>>
>>As always its better to have code and when I get some
>>time I'll try to write it up. Maybe its just a separate
>>classifier although I don't actually want two hardware
>>flow APIs.
>>
>>I see you dropped the RFC tag are you proposing we include
>>this now?
>>
>
>
>Actually I just realized i missed something very basic that
>Jiri said. I think i understand the tool being there for testing
>but i am assumed the same about the genlink api.
>Jiri, are you saying that genlink api is there to
>stay?
Yes, that I say. It is needed for flow manipulation, because such api does
not exist. As I stated earlier, I do not want to use switchdev genl for
anything other than flow manipulation.
>
>cheers,
>jamal
^ permalink raw reply
* Re: [patch net-next v2 8/9] switchdev: introduce Netlink API
From: Jiri Pirko @ 2014-09-20 8:25 UTC (permalink / raw)
To: Florian Fainelli
Cc: Jamal Hadi Salim, John Fastabend, netdev, davem, nhorman, andy,
tgraf, dborkman, ogerlitz, jesse, pshelar, azhou, ben, stephen,
jeffrey.t.kirsher, vyasevic, xiyou.wangcong, edumazet, sfeldma,
roopa, linville, dev, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck
In-Reply-To: <541D1327.4080905@gmail.com>
Sat, Sep 20, 2014 at 07:39:51AM CEST, f.fainelli@gmail.com wrote:
>On 09/19/14 15:18, Jamal Hadi Salim wrote:
>>On 09/19/14 18:12, John Fastabend wrote:
>>>On 09/19/2014 10:57 AM, Jamal Hadi Salim wrote:
>>>>On 09/19/14 11:49, Jiri Pirko wrote:
>>>>>Fri, Sep 19, 2014 at 05:25:48PM CEST, jhs@mojatatu.com wrote:
>>>>
>>>>>>Is this just a temporary test tool? Otherwise i dont see reason
>>>>>>for its existence (or the API that it feeds on).
>>>>>
>>>>>Please read the conversation I had with Pravin and Jesse in v1 thread.
>>>>>Long story short they like to have the api separated from ovs datapath
>>>>>so ovs daemon can use it to directly communicate with driver. Also John
>>>>>Fastabend requested a way to work with driver flows without using
>>>>>ovs ->
>>>>>that was the original reason I created switchdev genl api.
>>>>>
>>>>>Regarding the "sw" tool, yes it is for testing purposes now. ovs daemon
>>>>>will use directly switchdev genl api.
>>>>>
>>>>>I hope I cleared this out.
>>>>>
>>>>
>>>>It is - thanks Jiri.
>>>>
>>>>cheers,
>>>>jamal
>>>
>>>Hi Jiri,
>>>
>>>I was considering a slightly different approach where the
>>>device would report via netlink the fields/actions it
>>>supported rather than creating pre-defined enums for every
>>>possible key.
>>>
>>>I already need to have an API to report fields/matches
>>>that are being supported why not have the device report
>>>the headers as header fields (len, offset) and the
>>>associated parse graph the hardware uses? Vendors should
>>>have this already to describe/design their real hardware.
>>>
>>>As always its better to have code and when I get some
>>>time I'll try to write it up. Maybe its just a separate
>>>classifier although I don't actually want two hardware
>>>flow APIs.
>>>
>>>I see you dropped the RFC tag are you proposing we include
>>>this now?
>>>
>>
>>
>>Actually I just realized i missed something very basic that
>>Jiri said. I think i understand the tool being there for testing
>>but i am assumed the same about the genlink api.
>>Jiri, are you saying that genlink api is there to
>>stay?
>
>So, I really have mixed feelings about this netlink API, in particular
>because it is not clear to me where is the line between what should be a
>network device ndo operation, what should be an ethtool command, what should
>be a netlink message, and the rest.
Well as I said, this api should serve for flow manipulation only,
therefore swdev flow related ndos are used.
>
>I can certainly acknowledge the fact that manipulating flows is not ideal
>with the current set of tools, but really once we are there with netlink, how
>far are we from not having any network devices at all, and how does that
>differ from OpenWrt's swconfig in the end [1]?
I'm all ears on proposals how to make flow manipulation better.
>
>[1]: https://lwn.net/Articles/571390/
>--
>Florian
^ permalink raw reply
* Re: [patch net-next v2 8/9] switchdev: introduce Netlink API
From: Jamal Hadi Salim @ 2014-09-20 10:19 UTC (permalink / raw)
To: Jiri Pirko
Cc: John Fastabend, netdev, davem, nhorman, andy, tgraf, dborkman,
ogerlitz, jesse, pshelar, azhou, ben, stephen, jeffrey.t.kirsher,
vyasevic, xiyou.wangcong, edumazet, sfeldma, f.fainelli, roopa,
linville, dev, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck
In-Reply-To: <20140920081702.GF1821@nanopsycho.orion>
On 09/20/14 04:17, Jiri Pirko wrote:
> Yes, that I say. It is needed for flow manipulation, because such api does
> not exist.
Come on Jiri!
The ovs guys are against this and now no *api exists*?
Write a 15 tuple classifier tc classifier and use it. I will be more
than happy to help you. I will get to it when we have basics L2 working
on real devices.
>As I stated earlier, I do not want to use switchdev genl for
> anything other than flow manipulation.
Totally unacceptable in my books. If the OVS guys want some way out
to be able to ride on some vendor sdks then that is their problem.
We shouldnt allow for such loopholes. This is why/how TOE never made it
in the kernel.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next v4 2/2] bonding: Simplify the xmit function for modes that use xmit_hash
From: Nikolay Aleksandrov @ 2014-09-20 10:19 UTC (permalink / raw)
To: Mahesh Bandewar
Cc: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, David Miller,
netdev, Eric Dumazet, Maciej Zenczykowski
In-Reply-To: <CAF2d9jjHbqpMCrS9Zm=rDO9w68TZddLztN_-QF8KBrLhZNMXWw@mail.gmail.com>
On 09/20/2014 02:09 AM, Mahesh Bandewar wrote:
> On Fri, Sep 19, 2014 at 4:06 AM, Nikolay Aleksandrov <nikolay@redhat.com> wrote:
>>
>> On 09/19/2014 12:00 PM, Nikolay Aleksandrov wrote:
>>> On 09/18/2014 11:53 PM, Mahesh Bandewar wrote:
>>>> Earlier change to use usable slave array for TLB mode had an additional
>>>> performance advantage. So extending the same logic to all other modes
>>>> that use xmit-hash for slave selection (viz 802.3AD, and XOR modes).
>>>> Also consolidating this with the earlier TLB change.
>>>>
>>>> The main idea is to build the usable slaves array in the control path
>>>> and use that array for slave selection during xmit operation.
>>>>
>>>> Measured performance in a setup with a bond of 4x1G NICs with 200
>>>> instances of netperf for the modes involved (3ad, xor, tlb)
>>>> cmd: netperf -t TCP_RR -H <TargetHost> -l 60 -s 5
>>>>
>>>> Mode TPS-Before TPS-After
>>>>
>>>> 802.3ad : 468,694 493,101
>>>> TLB (lb=0): 392,583 392,965
>>>> XOR : 475,696 484,517
>>>>
>>>> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
>>>> ---
>>>> v1:
>>>> (a) If bond_update_slave_arr() fails to allocate memory, it will overwrite
>>>> the slave that need to be removed.
>>>> (b) Freeing of array will assign NULL (to handle bond->down to bond->up
>>>> transition gracefully.
>>>> (c) Change from pr_debug() to pr_err() if bond_update_slave_arr() returns
>>>> failure.
>>>> (d) XOR: bond_update_slave_arr() will consider mii-mon, arp-mon cases and
>>>> will populate the array even if these parameters are not used.
>>>> (e) 3AD: Should handle the ad_agg_selection_logic correctly.
>>>> v2:
>>>> (a) Removed rcu_read_{un}lock() calls from array manipulation code.
>>>> (b) Slave link-events now refresh array for all these modes.
>>>> (c) Moved free-array call from bond_close() to bond_uninit().
>>>> v3:
>>>> (a) Fixed null pointer dereference.
>>>> (b) Removed bond->lock lockdep dependency.
>>>> v4:
>>>> (a) Made to changes to comply with Nikolay's locking changes
>>>> (b) Added a work-queue to refresh slave-array when RTNL is not held
>>>> (c) Array refresh happens ONLY with RTNL now.
>>>> (d) alloc changed from GFP_ATOMIC to GFP_KERNEL
>>>>
>> <<<snip>>>
>>>> @@ -3839,6 +4003,7 @@ static void bond_uninit(struct net_device *bond_dev)
>>>> struct bonding *bond = netdev_priv(bond_dev);
>>>> struct list_head *iter;
>>>> struct slave *slave;
>>>> + struct bond_up_slave *arr;
>>>>
>>>> bond_netpoll_cleanup(bond_dev);
>>>>
>>>> @@ -3847,6 +4012,12 @@ static void bond_uninit(struct net_device *bond_dev)
>>>> __bond_release_one(bond_dev, slave->dev, true);
>>>> netdev_info(bond_dev, "Released all slaves\n");
>>>>
>> Sorry but I just spotted a major problem, bond_3ad_unbind_slave() (called
>> from __bond_release_one) calls ad_agg_selection_logic() which can re-arm
>> the slave_arr work after it's supposed to be stopped here (i.e. the bond
>> device has been closed so all works should've been stopped) so we might
>> leak memory and access freed memory after all since it'll keep
>> re-scheduling itself until it can acquire rtnl which is after the bond
>> device has been destroyed.
>>
> This should not be a problem. ndo_close (bond_close()) is called
> before ndo_uninit(bond_uninit()), so the work-queues get cancelled
> there so if rearm tries to schedule some work after queue gets
> cancelled, it can't do much and wont harm anything.
> Hence there wont be any arrays built once it's free-ed completely and
> therefore no memory leak. I addded some instrumentation and tried
> following sequence -
>
> # modprobe bonding mode=4
> # ip link set bond0 up
> # [Add ip]
> # [Add default route]
> # ifenslave bond0 eth0 eth1 eth2 eth3
> ....
> [Run some backgound traffic. I used netperf.]
>
> # ip link bond0 down
>
> I did not see anything "bad" happening. Did your trial produced
> something unpleasant?
>
The test you've done is irrelevant to the situation that I described
because ndo_uninit() is called when the device is being destroyed. Moreover
the case I told you about would require to have an active aggregator and an
inactive one (i.e. so agg selection logic will get called), here is the result:
[ 428.916586] bond1 (unregistering): Removing an active aggregator
[ 428.916589] Failed to build slave-array.
[ 428.916849] bond1 (unregistering): Releasing active interface eth1
[ 428.920342] bond1 (unregistering): Released all slaves
[ 428.923043] Failed to update slave array from WT
[ 428.924098] Failed to update slave array from WT
[ 428.925125] Failed to update slave array from WT
[ 428.926120] Failed to update slave array from WT
[ 428.927096] Failed to update slave array from WT
[ 428.928101] Failed to update slave array from WT
[ 428.929120] Failed to update slave array from WT
[ 428.930086] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 428.930644] IP: [<ffffffff810aa37b>] __queue_work+0x7b/0x350
[ 428.930946] PGD 0
[ 428.931053] Oops: 0000 [#1] SMP
[ 428.931053] Modules linked in: sfc ptp pps_core mdio i2c_algo_bit mtd
bonding(O) snd_hda_codec_generic joydev crct10dif_pclmul crc32_pclmul
i2c_piix4 ppdev crc32c_intel ghash_clmulni_intel parport_pc snd_hda_intel
snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_timer 9pnet_virtio
snd 9pnet pcspkr parport i2ccore serio_raw virtio_console virtio_balloon
pvpanic soundcore virtio_blk virtio_net ata_generic floppy pata_acpi
virtio_pci virtio_ring virtio
[ 428.935022] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O
3.17.0-rc4+ #30
[ 428.935022] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 428.935022] task: ffffffff81c1b460 ti: ffffffff81c00000 task.ti:
ffffffff81c00000
[ 428.935022] RIP: 0010:[<ffffffff810aa37b>] [<ffffffff810aa37b>]
__queue_work+0x7b/0x350
[ 428.935022] RSP: 0018:ffff88005f003e28 EFLAGS: 00010086
[ 428.935022] RAX: ffff88005c05c800 RBX: 0000000000000000 RCX:
0000000000000000
[ 428.935022] RDX: 0000000000000000 RSI: 0000000000000006 RDI:
ffff88005a4fbd58
[ 428.935022] RBP: ffff88005f003e60 R08: 0000000000000046 R09:
ffffffff8225abc2
[ 428.935022] R10: 0000000000000004 R11: 0000000000000005 R12:
ffff88005a4fbd58
[ 428.935022] R13: 0000000000000008 R14: ffff88004b211800 R15:
00000000000102f0
[ 428.935022] FS: 0000000000000000(0000) GS:ffff88005f000000(0000)
knlGS:0000000000000000
[ 428.935022] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 428.935022] CR2: 0000000000000000 CR3: 000000004abde000 CR4:
00000000000406f0
[ 428.935022] Stack:
[ 428.935022] 0a19522f72b12222 0000000081c1b460 ffffffff8225abc0
ffff88005a4fbd78
[ 428.935022] 0000000000000101 ffffffff810aa650 ffff88005a4fbd58
ffff88005f003e70
[ 428.935022] ffffffff810aa668 ffff88005f003ea8 ffffffff810f3536
ffffffff8225abc0
[ 428.935022] Call Trace:
[ 428.935022] <IRQ>
[ 428.935022]
[ 428.935022] [<ffffffff810aa650>] ? __queue_work+0x350/0x350
[ 428.935022] [<ffffffff810aa668>] delayed_work_timer_fn+0x18/0x20
[ 428.935022] [<ffffffff810f3536>] call_timer_fn+0x36/0x120
[ 428.935022] [<ffffffff810aa650>] ? __queue_work+0x350/0x350
[ 428.935022] [<ffffffff810f38f5>] run_timer_softirq+0x1a5/0x320
[ 428.935022] [<ffffffff81096dc5>] __do_softirq+0xf5/0x2b0
[ 428.935022] [<ffffffff810971fd>] irq_exit+0xbd/0xd0
[ 428.935022] [<ffffffff8173b715>] smp_apic_timer_interrupt+0x45/0x60
[ 428.935022] [<ffffffff8173981d>] apic_timer_interrupt+0x6d/0x80
[ 428.935022] <EOI>
[ 428.935022]
[ 428.935022] [<ffffffff810581c6>] ? native_safe_halt+0x6/0x10
[ 428.935022] [<ffffffff8101f36f>] default_idle+0x1f/0xe0
[ 428.935022] [<ffffffff8101fd8f>] arch_cpu_idle+0xf/0x20
[ 428.935022] [<ffffffff810d25dd>] cpu_startup_entry+0x38d/0x3c0
[ 428.935022] [<ffffffff81722927>] rest_init+0x87/0x90
[ 428.935022] [<ffffffff81d3510e>] start_kernel+0x482/0x4a3
[ 428.935022] [<ffffffff81d34a85>] ? set_init_arg+0x53/0x53
[ 428.935022] [<ffffffff81d34120>] ? early_idt_handlers+0x120/0x120
[ 428.935022] [<ffffffff81d345ee>] x86_64_start_reservations+0x2a/0x2c
[ 428.935022] [<ffffffff81d3473d>] x86_64_start_kernel+0x14d/0x170
[ 428.935022] Code: 84 bb 01 00 00 a8 02 0f 85 eb 00 00 00 48 63 45 d4 49
8b 9e 08 01 00 00 48 03 1c c5 60 fa d0 81 4c 89 e7 e8 18 f5 ff ff 48 85 c0
<48> 8b 3b 0f 84 7c 01 00 00 48 39 c7 0f 84 73 01 00 00 48 89 c7
[ 428.935022] RIP [<ffffffff810aa37b>] __queue_work+0x7b/0x350
[ 428.935022] RSP <ffff88005f003e28>
[ 428.935022] CR2: 0000000000000000
This is because it keeps trying to re-schedule even though the interface's
memory has been freed.
While testing this I spotted another issue as well - Failed to build
slave_arr message has been printed too many times because you print it in
3ad mode when there's no active aggregator (bond_3ad_get_active_agg_info
check in bond_update_slave_arr) which leads to re-scheduling which also
lead to a deadlock.
>>>> + arr = rtnl_dereference(bond->slave_arr);
>>>> + if (arr) {
>>>> + kfree_rcu(arr, rcu);
>>>> + RCU_INIT_POINTER(bond->slave_arr, NULL);
>>>> + }
>>>> +
>>>> list_del(&bond->bond_list);
>>>>
>>>> bond_debug_unregister(bond);
>>>> diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
>>>> index 98dc0d7ad731..4635b175256a 100644
>>>> --- a/drivers/net/bonding/bonding.h
>>>> +++ b/drivers/net/bonding/bonding.h
>>>> @@ -177,6 +177,12 @@ struct slave {
>>>> struct kobject kobj;
>>>> };
>>>>
>>>> +struct bond_up_slave {
>>>> + unsigned int count;
>>>> + struct rcu_head rcu;
>>>> + struct slave *arr[0];
>>>> +};
>>>> +
>>>> /*
>>>> * Link pseudo-state only used internally by monitors
>>>> */
>>>> @@ -191,6 +197,7 @@ struct bonding {
>>>> struct slave __rcu *curr_active_slave;
>>>> struct slave __rcu *current_arp_slave;
>>>> struct slave __rcu *primary_slave;
>>>> + struct bond_up_slave __rcu *slave_arr; /* Array of usable slaves */
>>>> bool force_primary;
>>>> s32 slave_cnt; /* never change this value outside the attach/detach wrappers */
>>>> int (*recv_probe)(const struct sk_buff *, struct bonding *,
>>>> @@ -220,6 +227,7 @@ struct bonding {
>>>> struct delayed_work alb_work;
>>>> struct delayed_work ad_work;
>>>> struct delayed_work mcast_work;
>>>> + struct delayed_work slave_arr_work;
>>>> #ifdef CONFIG_DEBUG_FS
>>>> /* debugging support via debugfs */
>>>> struct dentry *debug_dir;
>>>> @@ -531,6 +539,8 @@ const char *bond_slave_link_status(s8 link);
>>>> struct bond_vlan_tag *bond_verify_device_path(struct net_device *start_dev,
>>>> struct net_device *end_dev,
>>>> int level);
>>>> +int bond_update_slave_arr(struct bonding *bond, struct slave *skipslave);
>>>> +void bond_slave_arr_work_rearm(struct bonding *bond);
>>>>
>>>> #ifdef CONFIG_PROC_FS
>>>> void bond_create_proc_entry(struct bonding *bond);
>>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
^ permalink raw reply
* Hello Dear,
From: Miss. Nasirah Adams @ 2014-09-20 10:28 UTC (permalink / raw)
--
Hello Dear,
My name is Miss. Nasirah Adams from Libya presently residing in
Burkina Faso.I was impressed to seek my soul mate, and also i like to
establish a long lasting relationship with you. I will be waiting for
your reply so that i will give you my picture and more about me.
Thanks,waiting to hear from you soonest.
Love From,
Miss. Nasirah Adams Ali.
^ permalink raw reply
* Re: [patch net-next v2 8/9] switchdev: introduce Netlink API
From: Jamal Hadi Salim @ 2014-09-20 10:31 UTC (permalink / raw)
To: Scott Feldman, Roopa Prabhu
Cc: Jiri Pirko, netdev, davem, nhorman, andy, tgraf, dborkman,
ogerlitz, jesse, pshelar, azhou, ben, stephen, jeffrey.t.kirsher,
vyasevic, xiyou.wangcong, john.r.fastabend, edumazet, f.fainelli,
linville, dev, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, Shrijeet Mukherjee
In-Reply-To: <DDC24110-C3F5-470F-B9BE-1D1792415D1E@cumulusnetworks.com>
On 09/20/14 04:10, Scott Feldman wrote:
>
> On Sep 19, 2014, at 8:41 PM, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
>
>
> Existing rtnetlink isn’t available to swdev without some kind of snooping the echoes from the various kernel components
>(bridge, fib, etc).
You have made this claim before Scott and I am still not following.
Why do we need to echo things to get FDB or FIB to work? device ops for
FDB offload for example already exist. I think they need to be
revamped, but that consensus can be reasonably reached. Why do we
need this flow api for such activities?
cheers,
jamal
^ permalink raw reply
* [PATCH] ixgbe: delete one duplicate marcro definition of IXGBE_MAX_L2A_QUEUES
From: Ethan Zhao @ 2014-09-20 10:53 UTC (permalink / raw)
To: jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan,
carolyn.wyborny, donald.c.skidmore, gregory.v.rose,
alexander.h.duyck, john.ronciak, mitch.a.williams
Cc: e1000-devel, netdev, Ethan Zhao, linux.nics, linux-kernel
There is typo in ixgbe.h, two marcro definition of IXGBE_MAX_L2A_QUEUES to 4,
delete one, clear the compiler warning.
Signed-off-by: Ethan Zhao <ethan.zhao@oracle.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index ac9f214..bfb2c23 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -307,7 +307,6 @@ enum ixgbe_ring_f_enum {
#define MAX_RX_QUEUES (IXGBE_MAX_FDIR_INDICES + 1)
#define MAX_TX_QUEUES (IXGBE_MAX_FDIR_INDICES + 1)
#define IXGBE_MAX_L2A_QUEUES 4
-#define IXGBE_MAX_L2A_QUEUES 4
#define IXGBE_BAD_L2A_QUEUE 3
#define IXGBE_MAX_MACVLANS 31
#define IXGBE_MAX_DCBMACVLANS 8
--
1.7.1
------------------------------------------------------------------------------
Slashdot TV. Video for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
* Re: [patch net-next v2 8/9] switchdev: introduce Netlink API
From: Thomas Graf @ 2014-09-20 10:53 UTC (permalink / raw)
To: Jiri Pirko
Cc: John Fastabend, Jamal Hadi Salim, netdev, davem, nhorman, andy,
dborkman, ogerlitz, jesse, pshelar, azhou, ben, stephen,
jeffrey.t.kirsher, vyasevic, xiyou.wangcong, edumazet, sfeldma,
f.fainelli, roopa, linville, dev, jasowang, ebiederm,
nicolas.dichtel, ryazanov.s.a, buytenh, aviadr, nbd,
alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck
In-Reply-To: <20140920081426.GE1821@nanopsycho.orion>
On 09/20/14 at 10:14am, Jiri Pirko wrote:
> Sat, Sep 20, 2014 at 12:12:12AM CEST, john.r.fastabend@intel.com wrote:
> >I was considering a slightly different approach where the
> >device would report via netlink the fields/actions it
> >supported rather than creating pre-defined enums for every
> >possible key.
> >
> >I already need to have an API to report fields/matches
> >that are being supported why not have the device report
> >the headers as header fields (len, offset) and the
> >associated parse graph the hardware uses? Vendors should
> >have this already to describe/design their real hardware.
>
> Hmm, let me think about this a bit more. I will try to figure out how to
> handle that. Sound logic though. Will try to incorporate the idea in the
> patchset.
I think this is the right track.
I agree with Jamal that there is no need for a new permanent and
separate Netlink interface for this. I think this would best be described
as a structure of nested Netlink attributes in the form John proposes
which is then embedded into existing Netlink interfaces such as rtnetlink
and OVS genl.
OVS can register new genl ops to check capabilities and insert
hardware flows which allows implementation of the offload decision in
user space and allows for arbitary combination of hardware and software
flows. It also allows to run a eBPF software data path in combination
with a hardware flow setup.
rtnetlink can embed the nested attribute structure into existing APIs
to allow feature capability detection from user space, statistic
reporting and optional direct hardware offload if a transaprent
offload is not feasible. Would that work for you John?
I think we should focus on getting the layering right and make it
generic enough so we allow evolving naturally.
^ permalink raw reply
* Re: [patch net-next v2 8/9] switchdev: introduce Netlink API
From: Thomas Graf @ 2014-09-20 11:01 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Jiri Pirko, John Fastabend, netdev, davem, nhorman, andy,
dborkman, ogerlitz, jesse, pshelar, azhou, ben, stephen,
jeffrey.t.kirsher, vyasevic, xiyou.wangcong, edumazet, sfeldma,
f.fainelli, roopa, linville, dev, jasowang, ebiederm,
nicolas.dichtel, ryazanov.s.a, buytenh, aviadr, nbd,
alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck
In-Reply-To: <541D54BA.6070709@mojatatu.com>
On 09/20/14 at 06:19am, Jamal Hadi Salim wrote:
> The ovs guys are against this and now no *api exists*?
> Write a 15 tuple classifier tc classifier and use it. I will be more
> than happy to help you. I will get to it when we have basics L2 working
> on real devices.
Nothing speaks against having such a tc classifier. In fact, having
the interface consist of only an embedded Netlink attribute structure
would allow for such a classifier in a very straight forward way.
That doesn't mean everybody should be forced to use the stateful
tc interface.
> Totally unacceptable in my books. If the OVS guys want some way out
> to be able to ride on some vendor sdks then that is their problem.
> We shouldnt allow for such loopholes. This is why/how TOE never made it
> in the kernel.
No need for false accusations here. Nobody ever mentioned vendor SDKs.
The statement was that the requirement of deriving hardware flows from
software flows *in the kernel* is not flexible enough for the future
for reasons such as:
1) The OVS software data path might be based on eBPF in the future and
it is unclear how we could derive hardware flows from that
transparently.
2) Depending on hardware capabilities. Hardware flows might need to be
assisted by software flow counterparts and it is believed that it
is the wrong approach to push all the necessary context for the
decision down into the kernel. This can be argued about and I don't
feel strongly either way.
^ permalink raw reply
* Re: [patch net-next v2 8/9] switchdev: introduce Netlink API
From: Jamal Hadi Salim @ 2014-09-20 11:32 UTC (permalink / raw)
To: Thomas Graf
Cc: Jiri Pirko, John Fastabend, netdev, davem, nhorman, andy,
dborkman, ogerlitz, jesse, pshelar, azhou, ben, stephen,
jeffrey.t.kirsher, vyasevic, xiyou.wangcong, edumazet, sfeldma,
f.fainelli, roopa, linville, dev, jasowang, ebiederm,
nicolas.dichtel, ryazanov.s.a, buytenh, aviadr, nbd,
alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck
In-Reply-To: <20140920110121.GB29419@casper.infradead.org>
On 09/20/14 07:01, Thomas Graf wrote:
> Nothing speaks against having such a tc classifier. In fact, having
> the interface consist of only an embedded Netlink attribute structure
> would allow for such a classifier in a very straight forward way.
>
> That doesn't mean everybody should be forced to use the stateful
> tc interface.
>
Agreed. The response was to Jiri's strange statement that now that
he cant use OVS, there is no such api. I point to tc as very capable of
such usage.
> No need for false accusations here. Nobody ever mentioned vendor SDKs.
>
I am sorry to have tied the two together. Maybe not OVS but the approach
described is heaven for vendor SDKs.
> The statement was that the requirement of deriving hardware flows from
> software flows *in the kernel* is not flexible enough for the future
> for reasons such as:
>
> 1) The OVS software data path might be based on eBPF in the future and
> it is unclear how we could derive hardware flows from that
> transparently.
>
Who says you cant put BPF in hardware?
And why is OVS defining how BPF should evolve or how it should be used?
> 2) Depending on hardware capabilities. Hardware flows might need to be
> assisted by software flow counterparts and it is believed that it
> is the wrong approach to push all the necessary context for the
> decision down into the kernel. This can be argued about and I don't
> feel strongly either way.
>
Pointing to the current FDB offload: You can select to bypass
and not use s/ware.
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v2 8/9] switchdev: introduce Netlink API
From: Thomas Graf @ 2014-09-20 11:51 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Jiri Pirko, John Fastabend, netdev, davem, nhorman, andy,
dborkman, ogerlitz, jesse, pshelar, azhou, ben, stephen,
jeffrey.t.kirsher, vyasevic, xiyou.wangcong, edumazet, sfeldma,
f.fainelli, roopa, linville, dev, jasowang, ebiederm,
nicolas.dichtel, ryazanov.s.a, buytenh, aviadr, nbd,
alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck
In-Reply-To: <541D65CE.7080108@mojatatu.com>
On 09/20/14 at 07:32am, Jamal Hadi Salim wrote:
> I am sorry to have tied the two together. Maybe not OVS but the approach
> described is heaven for vendor SDKs.
I fail to see the connection. You can use switch vendor SDK no matter
how we define the kernel APIs. They already exist and have been
designed in a way to be completely indepenedent from the kernel.
Are you referring to vendor specific decisions in user space in
general? I believe that the whole point of swdev is to provide *that*
level of abstraction so decisions can be made in a vendor neutral way.
> >The statement was that the requirement of deriving hardware flows from
> >software flows *in the kernel* is not flexible enough for the future
> >for reasons such as:
> >
> >1) The OVS software data path might be based on eBPF in the future and
> > it is unclear how we could derive hardware flows from that
> > transparently.
> >
>
> Who says you cant put BPF in hardware?
I don't think anybody is saying that. P4 is likely a reality soon. But
we definitely want hardware offload in a BPF world even if the hardware
can't do BPF yet.
> And why is OVS defining how BPF should evolve or how it should be used?
Not sure I understand. OVS would be a user of eBPF just like tracing,
xt_BPF, socket filter, ...
> >2) Depending on hardware capabilities. Hardware flows might need to be
> > assisted by software flow counterparts and it is believed that it
> > is the wrong approach to push all the necessary context for the
> > decision down into the kernel. This can be argued about and I don't
> > feel strongly either way.
> >
>
> Pointing to the current FDB offload: You can select to bypass
> and not use s/ware.
As I said, this can be argued about. It would require to push a lot of
context into the kernel though. The FDB offload is relatively trivial
in comparison to the complexity OVS user space can handle. I can't think
of any reasons why to complicate the kernel further with OVS specific
knowledge as long as we can guarantee the vendor abstraction.
^ permalink raw reply
* [PATCH net-next] ipv6: mld: answer mldv2 queries with mldv1 reports in mldv1 fallback
From: Daniel Borkmann @ 2014-09-20 12:03 UTC (permalink / raw)
To: davem; +Cc: hannes, netdev
RFC2710 (MLDv1), section 3.7. says:
The length of a received MLD message is computed by taking the
IPv6 Payload Length value and subtracting the length of any IPv6
extension headers present between the IPv6 header and the MLD
message. If that length is greater than 24 octets, that indicates
that there are other fields present *beyond* the fields described
above, perhaps belonging to a *future backwards-compatible* version
of MLD. An implementation of the version of MLD specified in this
document *MUST NOT* send an MLD message longer than 24 octets and
MUST ignore anything past the first 24 octets of a received MLD
message.
RFC3810 (MLDv2), section 8.2.1. states for *listeners* regarding
presence of MLDv1 routers:
In order to be compatible with MLDv1 routers, MLDv2 hosts MUST
operate in version 1 compatibility mode. [...] When Host
Compatibility Mode is MLDv2, a host acts using the MLDv2 protocol
on that interface. When Host Compatibility Mode is MLDv1, a host
acts in MLDv1 compatibility mode, using *only* the MLDv1 protocol,
on that interface. [...]
While section 8.3.1. specifies *router* behaviour regarding presence
of MLDv1 routers:
MLDv2 routers may be placed on a network where there is at least
one MLDv1 router. The following requirements apply:
If an MLDv1 router is present on the link, the Querier MUST use
the *lowest* version of MLD present on the network. This must be
administratively assured. Routers that desire to be compatible
with MLDv1 MUST have a configuration option to act in MLDv1 mode;
if an MLDv1 router is present on the link, the system administrator
must explicitly configure all MLDv2 routers to act in MLDv1 mode.
When in MLDv1 mode, the Querier MUST send periodic General Queries
truncated at the Multicast Address field (i.e., 24 bytes long),
and SHOULD also warn about receiving an MLDv2 Query (such warnings
must be rate-limited). The Querier MUST also fill in the Maximum
Response Delay in the Maximum Response Code field, i.e., the
exponential algorithm described in section 5.1.3. is not used. [...]
That means that we should not get queries from different versions of
MLD. When there's a MLDv1 router present, MLDv2 enforces truncation
and MRC == MRD (both fields are overlapping within the 24 octet range).
Section 8.3.2. specifies behaviour in the presence of MLDv1 multicast
address *listeners*:
MLDv2 routers may be placed on a network where there are hosts
that have not yet been upgraded to MLDv2. In order to be compatible
with MLDv1 hosts, MLDv2 routers MUST operate in version 1 compatibility
mode. MLDv2 routers keep a compatibility mode per multicast address
record. The compatibility mode of a multicast address is determined
from the Multicast Address Compatibility Mode variable, which can be
in one of the two following states: MLDv1 or MLDv2.
The Multicast Address Compatibility Mode of a multicast address
record is set to MLDv1 whenever an MLDv1 Multicast Listener Report is
*received* for that multicast address. At the same time, the Older
Version Host Present timer for the multicast address is set to Older
Version Host Present Timeout seconds. The timer is re-set whenever a
new MLDv1 Report is received for that multicast address. If the Older
Version Host Present timer expires, the router switches back to
Multicast Address Compatibility Mode of MLDv2 for that multicast
address. [...]
That means, what can happen is the following scenario, that hosts can
act in MLDv1 compatibility mode when they previously have received an
MLDv1 query (or, simply operate in MLDv1 mode-only); and at the same
time, an MLDv2 router could start up and transmits MLDv2 startup query
messages while being unaware of the current operational mode.
Given RFC2710, section 3.7 we would need to answer to that with an MLDv1
listener report, so that the router according to RFC3810, section 8.3.2.
would receive that and internally switch to MLDv1 compatibility as well.
Right now, I believe since the initial implementation of MLDv2, Linux
hosts would just silently drop such MLDv2 queries instead of replying
with an MLDv1 listener report, which would prevent a MLDv2 router going
into fallback mode (until it receives other MLDv1 queries).
Since the mapping of MRC to MRD in exactly such cases can make use of
the exponential algorithm from 5.1.3, we cannot [strictly speaking] be
aware in MLDv1 of the encoding in MRC, it seems also not mentioned by
the RFC. Since encodings are the same up to 32767, assume in such a
situation this value as a hard upper limit we would clamp. We have asked
one of the RFC authors on that regard, and he mentioned that there seem
not to be any implementations that make use of that exponential algorithm
on startup messages. In any case, this patch fixes this MLD
interoperability issue.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
[ Sending to net-next as it's nothing critical and nobody was screaming
out loud for so many years, so it can linger a bit in net-next first. ]
include/net/mld.h | 5 ++++-
net/ipv6/mcast.c | 41 +++++++++++++++++++++++++++++++----------
2 files changed, 35 insertions(+), 11 deletions(-)
diff --git a/include/net/mld.h b/include/net/mld.h
index faa1d16..5e9be79 100644
--- a/include/net/mld.h
+++ b/include/net/mld.h
@@ -88,12 +88,15 @@ struct mld2_query {
#define MLDV2_QQIC_EXP(value) (((value) >> 4) & 0x07)
#define MLDV2_QQIC_MAN(value) ((value) & 0x0f)
+#define MLD_EXP_MIN_LIMIT 32768UL
+#define MLDV1_MRD_MAX_COMPAT (MLD_EXP_MIN_LIMIT - 1)
+
static inline unsigned long mldv2_mrc(const struct mld2_query *mlh2)
{
/* RFC3810, 5.1.3. Maximum Response Code */
unsigned long ret, mc_mrc = ntohs(mlh2->mld2q_mrc);
- if (mc_mrc < 32768) {
+ if (mc_mrc < MLD_EXP_MIN_LIMIT) {
ret = mc_mrc;
} else {
unsigned long mc_man, mc_exp;
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 592eba6..9648de2 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -1237,7 +1237,7 @@ static void mld_update_qri(struct inet6_dev *idev,
}
static int mld_process_v1(struct inet6_dev *idev, struct mld_msg *mld,
- unsigned long *max_delay)
+ unsigned long *max_delay, bool v1_query)
{
unsigned long mldv1_md;
@@ -1245,11 +1245,32 @@ static int mld_process_v1(struct inet6_dev *idev, struct mld_msg *mld,
if (mld_in_v2_mode_only(idev))
return -EINVAL;
- /* MLDv1 router present */
mldv1_md = ntohs(mld->mld_maxdelay);
+
+ /* When in MLDv1 fallback and a MLDv2 router start-up being
+ * unaware of current MLDv1 operation, the MRC == MRD mapping
+ * only works when the exponential algorithm is not being
+ * used (as MLDv1 is unaware of such things).
+ *
+ * According to the RFC author, the MLDv2 implementations
+ * he's aware of all use a MRC < 32768 on start up queries.
+ *
+ * Thus, should we *ever* encounter something else larger
+ * than that, just assume the maximum possible within our
+ * reach.
+ */
+ if (!v1_query)
+ mldv1_md = min(mldv1_md, MLDV1_MRD_MAX_COMPAT);
+
*max_delay = max(msecs_to_jiffies(mldv1_md), 1UL);
- mld_set_v1_mode(idev);
+ /* MLDv1 router present: we need to go into v1 mode *only*
+ * when an MLDv1 query is received as per section 9.12. of
+ * RFC3810! And we know from RFC2710 section 3.7 that MLDv1
+ * queries MUST be of exactly 24 octets.
+ */
+ if (v1_query)
+ mld_set_v1_mode(idev);
/* cancel MLDv2 report timer */
mld_gq_stop_timer(idev);
@@ -1264,10 +1285,6 @@ static int mld_process_v1(struct inet6_dev *idev, struct mld_msg *mld,
static int mld_process_v2(struct inet6_dev *idev, struct mld2_query *mld,
unsigned long *max_delay)
{
- /* hosts need to stay in MLDv1 mode, discard MLDv2 queries */
- if (mld_in_v1_mode(idev))
- return -EINVAL;
-
*max_delay = max(msecs_to_jiffies(mldv2_mrc(mld)), 1UL);
mld_update_qrv(idev, mld);
@@ -1324,8 +1341,11 @@ int igmp6_event_query(struct sk_buff *skb)
!(group_type&IPV6_ADDR_MULTICAST))
return -EINVAL;
- if (len == MLD_V1_QUERY_LEN) {
- err = mld_process_v1(idev, mld, &max_delay);
+ if (len < MLD_V1_QUERY_LEN) {
+ return -EINVAL;
+ } else if (len == MLD_V1_QUERY_LEN || mld_in_v1_mode(idev)) {
+ err = mld_process_v1(idev, mld, &max_delay,
+ len == MLD_V1_QUERY_LEN);
if (err < 0)
return err;
} else if (len >= MLD_V2_QUERY_LEN_MIN) {
@@ -1357,8 +1377,9 @@ int igmp6_event_query(struct sk_buff *skb)
mlh2 = (struct mld2_query *)skb_transport_header(skb);
mark = 1;
}
- } else
+ } else {
return -EINVAL;
+ }
read_lock_bh(&idev->lock);
if (group_type == IPV6_ADDR_ANY) {
--
1.9.0
^ permalink raw reply related
* Re: [patch net-next v2 8/9] switchdev: introduce Netlink API
From: Jamal Hadi Salim @ 2014-09-20 12:35 UTC (permalink / raw)
To: Thomas Graf
Cc: ryazanov.s.a-Re5JQEeQqe8AvxtiuMwx3w,
jasowang-H+wXaHxf7aLQT0dZR+AlfA, John Fastabend,
Neil.Jerram-QnUH15yq9NYqDJ6do+/SaQ,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, andy-QlMahl40kYEqcZcGjlUOXw,
dev-yBygre7rU0TnMu66kgdUjQ, nbd-p3rKhJxN3npAfugRpC6u6w,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, ronye-VPRAkNaXOzVWk0Htik3J/w,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
ogerlitz-VPRAkNaXOzVWk0Htik3J/w, ben-/+tVBieCtBitmTQ+vhA3Yw,
buytenh-OLH4Qvv75CYX/NnBR394Jw,
alexander.h.duyck-ral2JQCrhuEAvxtiuMwx3w, Jiri Pirko,
simon.horman-wFxRvT7yatFl57MIdRCFDg,
roopa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR,
aviadr-VPRAkNaXOzVWk0Htik3J/w,
nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w,
vyasevic-H+wXaHxf7aLQT0dZR+AlfA, nhorman-2XuSBdqkA4R54TAoqtyWWQ,
netdev-u79uwXL29TY76Z2rM5mHXA,
stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
dborkman-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <20140920115140.GA3777-FZi0V3Vbi30CUdFEqe4BF2D2FQJk+8+b@public.gmane.org>
On 09/20/14 07:51, Thomas Graf wrote:
> I fail to see the connection. You can use switch vendor SDK no matter
> how we define the kernel APIs. They already exist and have been
> designed in a way to be completely indepenedent from the kernel.
>
> Are you referring to vendor specific decisions in user space in
> general? I believe that the whole point of swdev is to provide *that*
> level of abstraction so decisions can be made in a vendor neutral way.
>
I am not against the swdev idea. I think we have disagreements
for the general classification/action interface how that should look
like - but that is resolvable with correct interfaces.
The vendor neutral way *already exists* via current netlink
abstractions that existing tools use. When we need to add new
interfaces then we should.
> I don't think anybody is saying that. P4 is likely a reality soon. But
> we definitely want hardware offload in a BPF world even if the hardware
> can't do BPF yet.
>
I dont think we have contradictions. We are speaking past each other.
You implied that in the future OVS s/w path might be based on BPF.
I implied BPF itself could be offloaded and stands on its own merit
and should work if we have the correct interface. As an example,
I dont care about P4 or OVS - but i have no problem if they use
the common interfaces provided by Linux. i.e
If i want to build a little cpu running the BPF instruction set
and use that as my offload then that interface should work and if
it doesnt i should provide extensions.
> Not sure I understand. OVS would be a user of eBPF just like tracing,
> xt_BPF, socket filter, ...
>
Ok, we are on the same page then.
> As I said, this can be argued about. It would require to push a lot of
> context into the kernel though. The FDB offload is relatively trivial
> in comparison to the complexity OVS user space can handle. I can't think
> of any reasons why to complicate the kernel further with OVS specific
> knowledge as long as we can guarantee the vendor abstraction.
>
I disagree. OVS maybe complex in that sense (I am sorry i am making
an assumption based on what you are saying) but i dont think there is
any other kernel subsystem that has this challenge.
Note: i am pointing to fdb only because it carries the concept of "put
this in hardware and/or software". I agree the fdb maybe reasonably
simpler.
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v2 8/9] switchdev: introduce Netlink API
From: Roopa Prabhu @ 2014-09-20 12:39 UTC (permalink / raw)
To: Jiri Pirko
Cc: Jamal Hadi Salim, netdev, davem, nhorman, andy, tgraf, dborkman,
ogerlitz, jesse, pshelar, azhou, ben, stephen, jeffrey.t.kirsher,
vyasevic, xiyou.wangcong, john.r.fastabend, edumazet, sfeldma,
f.fainelli, linville, dev, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck,
Shrijeet Mukherjee
In-Reply-To: <20140920080943.GD1821@nanopsycho.orion>
On 9/20/14, 1:09 AM, Jiri Pirko wrote:
> Sat, Sep 20, 2014 at 05:41:16AM CEST, roopa@cumulusnetworks.com wrote:
>> On 9/19/14, 8:49 AM, Jiri Pirko wrote:
>>> Fri, Sep 19, 2014 at 05:25:48PM CEST, jhs@mojatatu.com wrote:
>>>> On 09/19/14 09:49, Jiri Pirko wrote:
>>>>> This patch exposes switchdev API using generic Netlink.
>>>>> Example userspace utility is here:
>>>>> https://github.com/jpirko/switchdev
>>>>>
>>>> Is this just a temporary test tool? Otherwise i dont see reason
>>>> for its existence (or the API that it feeds on).
>>> Please read the conversation I had with Pravin and Jesse in v1 thread.
>>> Long story short they like to have the api separated from ovs datapath
>>> so ovs daemon can use it to directly communicate with driver. Also John
>>> Fastabend requested a way to work with driver flows without using ovs ->
>>> that was the original reason I created switchdev genl api.
>>>
>>> Regarding the "sw" tool, yes it is for testing purposes now. ovs daemon
>>> will use directly switchdev genl api.
>>>
>>> I hope I cleared this out.
>> We already have all the needed rtnetlink kernel api and userspace tools
>> around it to support all
>> switching asic features. ie, the rtnetlink api is the switchdev api. We can
>> do l2, l3, acl's with it.
>> Its unclear to me why we need another new netlink api. Which will mean none
>> of the existing tools to
>> create bridges etc will work on a switchdev.
> No one is proposing such API. Note that what I'm trying to solve in my
> patchset is FLOW world. There is only one API there, ovs genl. But the
> usage of that for hw offload purposes was nacked by ovs maintainer. Plus
> couple of people wanted to run the offloading independently on ovs
> instance. Therefore I introduced the switchdev genl, which takes care of
> that. No plan to extend it for other things you mentioned, just flows.
ok, That was not clear to me. Introducing a new genl api and calling it the
switchd dev api can result it non-flow creep into it in the future.
>
>
>> Which seems like going in the direction exactly opposite to what we had
>> discussed earlier.
> Nope. The previous discussion ignored flows.
>> If a non-ovs flow interface is needed from userspace, we can extend the
>> existing interface to include flows.
> How? You mean to extend rtnetlink? What advantage it would bring
> comparing to separate genl iface?
yes. Advantage would be that we dont have yet another parallel switchdev
netlink api.
>> I don't understand why we should replace the existing rtnetlink switchdev api
>> to accommodate flows.
> Sorry, I do not undertand what "existing rtnetlink switchdev api" you
> have on mind. Would you care to explain?
I am taking about existing rtnetlink api that bridge, ip link uses to
talk l2 and l3 to the kernel.
RTM_NEWROUTE etc.
^ permalink raw reply
* Re: [patch net-next v2 8/9] switchdev: introduce Netlink API
From: Roopa Prabhu @ 2014-09-20 12:51 UTC (permalink / raw)
To: Scott Feldman
Cc: ryazanov.s.a-Re5JQEeQqe8AvxtiuMwx3w,
jasowang-H+wXaHxf7aLQT0dZR+AlfA,
john.r.fastabend-ral2JQCrhuEAvxtiuMwx3w,
Neil.Jerram-QnUH15yq9NYqDJ6do+/SaQ,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, andy-QlMahl40kYEqcZcGjlUOXw,
dev-yBygre7rU0TnMu66kgdUjQ, nbd-p3rKhJxN3npAfugRpC6u6w,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, Shrijeet Mukherjee,
ronye-VPRAkNaXOzVWk0Htik3J/w,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
ogerlitz-VPRAkNaXOzVWk0Htik3J/w, ben-/+tVBieCtBitmTQ+vhA3Yw,
buytenh-OLH4Qvv75CYX/NnBR394Jw,
alexander.h.duyck-ral2JQCrhuEAvxtiuMwx3w, Jiri Pirko,
simon.horman-wFxRvT7yatFl57MIdRCFDg, Jamal Hadi Salim,
aviadr-VPRAkNaXOzVWk0Htik3J/w,
nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w,
vyasevic-H+wXaHxf7aLQT0dZR+AlfA, nhorman-2XuSBdqkA4R54TAoqtyWWQ,
netdev, stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
dborkman-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <DDC24110-C3F5-470F-B9BE-1D1792415D1E-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
On 9/20/14, 1:10 AM, Scott Feldman wrote:
> On Sep 19, 2014, at 8:41 PM, Roopa Prabhu <roopa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org> wrote:
>
>> On 9/19/14, 8:49 AM, Jiri Pirko wrote:
>>> Fri, Sep 19, 2014 at 05:25:48PM CEST, jhs-jkUAjuhPggJWk0Htik3J/w@public.gmane.org wrote:
>>>> On 09/19/14 09:49, Jiri Pirko wrote:
>>>>> This patch exposes switchdev API using generic Netlink.
>>>>> Example userspace utility is here:
>>>>> https://github.com/jpirko/switchdev
>>>>>
>>>> Is this just a temporary test tool? Otherwise i dont see reason
>>>> for its existence (or the API that it feeds on).
>>> Please read the conversation I had with Pravin and Jesse in v1 thread.
>>> Long story short they like to have the api separated from ovs datapath
>>> so ovs daemon can use it to directly communicate with driver. Also John
>>> Fastabend requested a way to work with driver flows without using ovs ->
>>> that was the original reason I created switchdev genl api.
>>>
>>> Regarding the "sw" tool, yes it is for testing purposes now. ovs daemon
>>> will use directly switchdev genl api.
>>>
>>> I hope I cleared this out.
>> We already have all the needed rtnetlink kernel api and userspace tools around it to support all
>> switching asic features. ie, the rtnetlink api is the switchdev api. We can do l2, l3, acl's with it.
>> Its unclear to me why we need another new netlink api. Which will mean none of the existing tools to
>> create bridges etc will work on a switchdev.
>> Which seems like going in the direction exactly opposite to what we had discussed earlier.
> Existing rtnetlink isn’t available to swdev without some kind of snooping the echoes from the various kernel components (bridge, fib, etc). With swdev_flow, as Jiri has defined it, there is an additional conversion needed to bridge the gap (bad expression, I know) between rtnetlink and swdev_flow. This conversion happens in the kernel components. For example, the bridge module, still driven from userspace by existing rtnetlink, will formulate the necessary swdev_flow insert/remove calls to the swdev driver such that HW will offload the fwd path.
>
> You have:
> user -> rtnetlink -> kernel -> netlink echo -> [some process] -> [some driver] -> HW
>
> Jiri has:
> user -> rtnetlink -> kernel -> swdev_* -> swdev driver -> HW
>
Keeping the goal to not change or not add a new userspace API in mind,
I have :
user -> rtnetlink -> kernel -> ndo_op -> swdev driver -> HW
Jiri has:
user -> genl (newapi) -> kernel -> swdev_* -> swdev driver -> HW
^ permalink raw reply
* action stats broken?
From: Jamal Hadi Salim @ 2014-09-20 13:17 UTC (permalink / raw)
To: john Fastabend, netdev@vger.kernel.org, Cong Wang
Sorry, dont have time to chase this today and it may be fixed in the
latest tree. Possibly recent patches or likely earlier patches
even.
It seems stats are no longer displaying for actions.
This is a net-next kernel. I have tried kernel 3.16.0-rc2
and 3.17.0-rc4 with same results.
Simple test case:
----
root@moja-1:~# tc actions add action drop index 4
root@moja-1:~# tc -s actions ls action gact
action order 0: gact action drop
random type none pass val 0
index 4 ref 1 bind 0 installed 9 sec used 4 sec
-----
What I would have expected to see is:
---
action order 0: gact action drop
random type none pass val 0
index 4 ref 1 bind 0 installed 9 sec used 4 sec
Sent 108948 bytes 1297 pkts (dropped 1297, overlimits 0)
---
cheers,
jamal
^ permalink raw reply
* net: stmmac glue layer for Amlogic Meson SoCs
From: Beniamino Galvani @ 2014-09-20 13:29 UTC (permalink / raw)
To: netdev
Cc: Giuseppe Cavallaro, David S. Miller, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Carlo Caione, Jerry Cao,
Victor Wan, linux-kernel, devicetree, Beniamino Galvani
Hi,
the Ethernet controller available in Amlogic Meson6 and Meson8 SoCs is
a Synopsys DesignWare MAC IP core, already supported by the stmmac
driver.
These patches add a glue layer to the driver for the platform-specific
settings required by the Amlogic variant.
This has been tested on a Amlogic S802 device with the initial Meson
support submitted by Carlo Caione [1].
[1] http://lwn.net/Articles/612000/
Beniamino Galvani (2):
net: stmmac: add Amlogic Meson glue layer
net: stmmac: meson: document device tree bindings
.../devicetree/bindings/net/meson-dwmac.txt | 25 ++++++++
drivers/net/ethernet/stmicro/stmmac/Kconfig | 10 ++++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c | 67 ++++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 3 +
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 +
6 files changed, 109 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/meson-dwmac.txt
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c
--
1.9.1
^ permalink raw reply
* [PATCH 1/2] net: stmmac: add Amlogic Meson glue layer
From: Beniamino Galvani @ 2014-09-20 13:29 UTC (permalink / raw)
To: netdev
Cc: Giuseppe Cavallaro, David S. Miller, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Carlo Caione, Jerry Cao,
Victor Wan, linux-kernel, devicetree, Beniamino Galvani
In-Reply-To: <1411219757-9201-1-git-send-email-b.galvani@gmail.com>
The Ethernet controller available in Meson6 and Meson8 SoCs is a
Synopsys DesignWare MAC IP core, already supported by the stmmac
driver.
This glue layer implements some platform-specific settings needed by
the Amlogic variant.
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 10 ++++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c | 67 ++++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 3 +
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 +
5 files changed, 84 insertions(+)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 2d09c11..b02d4a3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -26,6 +26,16 @@ config STMMAC_PLATFORM
If unsure, say N.
+config DWMAC_MESON
+ bool "Amlogic Meson dwmac support"
+ depends on STMMAC_PLATFORM && ARCH_MESON
+ help
+ Support for Ethernet controller on Amlogic Meson SoCs.
+
+ This selects the Amlogic Meson SoC glue layer support for
+ the stmmac device driver. This driver is used for Meson6 and
+ Meson8 SoCs.
+
config DWMAC_SOCFPGA
bool "SOCFPGA dwmac support"
depends on STMMAC_PLATFORM && MFD_SYSCON && (ARCH_SOCFPGA || COMPILE_TEST)
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 18695eb..0533d0b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_STMMAC_ETH) += stmmac.o
stmmac-$(CONFIG_STMMAC_PLATFORM) += stmmac_platform.o
stmmac-$(CONFIG_STMMAC_PCI) += stmmac_pci.o
+stmmac-$(CONFIG_DWMAC_MESON) += dwmac-meson.o
stmmac-$(CONFIG_DWMAC_SUNXI) += dwmac-sunxi.o
stmmac-$(CONFIG_DWMAC_STI) += dwmac-sti.o
stmmac-$(CONFIG_DWMAC_SOCFPGA) += dwmac-socfpga.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c
new file mode 100644
index 0000000..d225a60
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c
@@ -0,0 +1,67 @@
+/*
+ * Amlogic Meson DWMAC glue layer
+ *
+ * Copyright (C) 2014 Beniamino Galvani <b.galvani@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/device.h>
+#include <linux/ethtool.h>
+#include <linux/io.h>
+#include <linux/ioport.h>
+#include <linux/platform_device.h>
+#include <linux/stmmac.h>
+
+#define ETHMAC_SPEED_100 BIT(1)
+
+struct meson_dwmac {
+ struct device *dev;
+ void __iomem *reg;
+};
+
+static void meson6_dwmac_fix_mac_speed(void *priv, unsigned int speed)
+{
+ struct meson_dwmac *dwmac = priv;
+ unsigned int val;
+
+ val = readl(dwmac->reg);
+
+ switch (speed) {
+ case SPEED_10:
+ val &= ~ETHMAC_SPEED_100;
+ break;
+ case SPEED_100:
+ val |= ETHMAC_SPEED_100;
+ break;
+ }
+
+ writel(val, dwmac->reg);
+}
+
+static void *meson6_dwmac_setup(struct platform_device *pdev)
+{
+ struct meson_dwmac *dwmac;
+ struct resource *res;
+
+ dwmac = devm_kzalloc(&pdev->dev, sizeof(*dwmac), GFP_KERNEL);
+ if (!dwmac)
+ return ERR_PTR(-ENOMEM);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ dwmac->reg = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(dwmac->reg))
+ return dwmac->reg;
+
+ return dwmac;
+}
+
+const struct stmmac_of_data meson6_dwmac_data = {
+ .setup = meson6_dwmac_setup,
+ .fix_mac_speed = meson6_dwmac_fix_mac_speed,
+};
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 58097c0..4452889 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -137,6 +137,9 @@ void stmmac_disable_eee_mode(struct stmmac_priv *priv);
bool stmmac_eee_init(struct stmmac_priv *priv);
#ifdef CONFIG_STMMAC_PLATFORM
+#ifdef CONFIG_DWMAC_MESON
+extern const struct stmmac_of_data meson6_dwmac_data;
+#endif
#ifdef CONFIG_DWMAC_SUNXI
extern const struct stmmac_of_data sun7i_gmac_data;
#endif
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index bb524a9..6521717 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -30,6 +30,9 @@
#include "stmmac.h"
static const struct of_device_id stmmac_dt_ids[] = {
+#ifdef CONFIG_DWMAC_MESON
+ { .compatible = "amlogic,meson6-dwmac", .data = &meson6_dwmac_data},
+#endif
#ifdef CONFIG_DWMAC_SUNXI
{ .compatible = "allwinner,sun7i-a20-gmac", .data = &sun7i_gmac_data},
#endif
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] net: stmmac: meson: document device tree bindings
From: Beniamino Galvani @ 2014-09-20 13:29 UTC (permalink / raw)
To: netdev
Cc: Giuseppe Cavallaro, David S. Miller, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Carlo Caione, Jerry Cao,
Victor Wan, linux-kernel, devicetree, Beniamino Galvani
In-Reply-To: <1411219757-9201-1-git-send-email-b.galvani@gmail.com>
Add the device tree bindings documentation for the Amlogic Meson
variant of the Synopsys DesignWare MAC.
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
---
.../devicetree/bindings/net/meson-dwmac.txt | 25 ++++++++++++++++++++++
1 file changed, 25 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/meson-dwmac.txt
diff --git a/Documentation/devicetree/bindings/net/meson-dwmac.txt b/Documentation/devicetree/bindings/net/meson-dwmac.txt
new file mode 100644
index 0000000..ec633d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/meson-dwmac.txt
@@ -0,0 +1,25 @@
+* Amlogic Meson DWMAC Ethernet controller
+
+The device inherits all the properties of the dwmac/stmmac devices
+described in the file net/stmmac.txt with the following changes.
+
+Required properties:
+
+- compatible: should be "amlogic,meson6-dwmac" along with "snps,dwmac"
+ and any applicable more detailed version number
+ described in net/stmmac.txt
+
+- reg: should contain a register range for the dwmac controller and
+ another one for the Amlogic specific configuration
+
+Example:
+
+ ethmac: ethernet@c9410000 {
+ compatible = "amlogic,meson6-dwmac", "snps,dwmac";
+ reg = <0xc9410000 0x10000
+ 0xc1108108 0x4>;
+ interrupts = <0 8 1>;
+ interrupt-names = "macirq";
+ clocks = <&clk81>;
+ clock-names = "stmmaceth";
+ }
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next] ipv6: mld: answer mldv2 queries with mldv1 reports in mldv1 fallback
From: Hannes Frederic Sowa @ 2014-09-20 13:36 UTC (permalink / raw)
To: Daniel Borkmann, davem; +Cc: netdev
In-Reply-To: <1411214635-14136-1-git-send-email-dborkman@redhat.com>
On Sat, Sep 20, 2014, at 14:03, Daniel Borkmann wrote:
> Since the mapping of MRC to MRD in exactly such cases can make use of
> the exponential algorithm from 5.1.3, we cannot [strictly speaking] be
> aware in MLDv1 of the encoding in MRC, it seems also not mentioned by
> the RFC. Since encodings are the same up to 32767, assume in such a
> situation this value as a hard upper limit we would clamp. We have asked
> one of the RFC authors on that regard, and he mentioned that there seem
> not to be any implementations that make use of that exponential algorithm
> on startup messages. In any case, this patch fixes this MLD
> interoperability issue.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
^ permalink raw reply
* Re: action stats broken?
From: John Fastabend @ 2014-09-20 15:21 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: john Fastabend, netdev@vger.kernel.org, Cong Wang
In-Reply-To: <541D7E55.6070306@mojatatu.com>
On 09/20/2014 06:17 AM, Jamal Hadi Salim wrote:
>
> Sorry, dont have time to chase this today and it may be fixed in the
> latest tree. Possibly recent patches or likely earlier patches
> even.
>
> It seems stats are no longer displaying for actions.
> This is a net-next kernel. I have tried kernel 3.16.0-rc2
> and 3.17.0-rc4 with same results.
>
> Simple test case:
>
> ----
> root@moja-1:~# tc actions add action drop index 4
> root@moja-1:~# tc -s actions ls action gact
>
> action order 0: gact action drop
> random type none pass val 0
> index 4 ref 1 bind 0 installed 9 sec used 4 sec
> -----
>
> What I would have expected to see is:
> ---
> action order 0: gact action drop
> random type none pass val 0
> index 4 ref 1 bind 0 installed 9 sec used 4 sec
> Sent 108948 bytes 1297 pkts (dropped 1297, overlimits 0)
> ---
>
>
I'm looking into it which classifier? A basic u32 classifier attached
to the ingress qdisc seems to work. If your using u32 any hash tables,
or 'filter change' commands before this?
# tc actions add action drop index 4
# tc filter add dev p3p1 parent ffff:0 protocol ip prio 100 \
u32 match ip src 16.0.0.2 action gact index 4
#tc -s actions ls action gact
action order 0: gact action drop
random type none pass val 0
index 4 ref 2 bind 1 installed 142 sec used 0 sec
Action statistics:
Sent 840 bytes 10 pkt (dropped 10, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
> cheers,
> jamal
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
John Fastabend Intel Corporation
^ permalink raw reply
* Fwd: [Bug 84661] New: tc filter show from iproute2 does not work correctly on 32bit x86
From: Daniel Borkmann @ 2014-09-20 15:39 UTC (permalink / raw)
To: yangyingliang; +Cc: rider, netdev
In-Reply-To: <bug-84661-65011@https.bugzilla.kernel.org/>
[ Cc'ing Yang ]
-------- Original Message --------
Subject: [Bug 84661] New: tc filter show from iproute2 does not work correctly on 32bit x86
Date: Tue, 16 Sep 2014 11:47:20 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: dborkman@redhat.com
https://bugzilla.kernel.org/show_bug.cgi?id=84661
Bug ID: 84661
Summary: tc filter show from iproute2 does not work correctly
on 32bit x86
Product: Networking
Version: 2.5
Kernel Version: 3.14.17 and 3.16.1
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: shemminger@linux-foundation.org
Reporter: rider@altlinux.org
Regression: No
i tested this issue with kernels 3.14.x and 3.16.x. and iproute2-3.16.0
This commit:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=6a031f67c83aa175aedd10d4ae64750415ab57b0
breaking output tc filter show on 32bit systems.
This simple script shows the difference in the work on i586 and x86_64:
-------------------------
#!/bin/sh
dev=$1
tc qdisc add dev $dev root handle 1: htb default fffe
tc filter add dev $dev parent 1:0 protocol ip pref 10 u32
tc filter add dev $dev parent 1:0 protocol ip pref 10 handle 100: u32 divisor 8
tc filter add dev $dev parent 1:0 protocol ip pref 10 u32 ht 800:: match ip dst
10.21.10.0/21 hashkey mask 0x00000700 at 16 link 100:
tc filter show dev $dev
tc filter del dev $dev parent 1:0 protocol ip pref 10 u32 ht 800:: match ip dst
10.21.10.0/21 hashkey mask 0x00000700 at 16 link 100:
tc qdisc del dev $dev root handle 1: htb default fffe
---------------------------
output on i586:
#./script enp0s25
filter parent 1: protocol ip pref 10 u32
filter parent 1: protocol ip pref 10 u32 fh 100: ht divisor 8
filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1
output on x86_64:
# ./script eth0
filter parent 1: protocol ip pref 10 u32
filter parent 1: protocol ip pref 10 u32 fh 100: ht divisor 8
filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt
0 link 100:
match 0a150800/fffff800 at 16
hash mask 00000700 at 16
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ 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