* [PATCH 1/6] rtlwifi: Change logging level for key change
From: Larry Finger @ 2015-01-23 17:10 UTC (permalink / raw)
To: kvalo-sgV2jX0FEOL9JmXXK+q4OQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Larry Finger,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1422033044-7461-1-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
A recent change in key handling included logging of these changes for
all debug levels. Such key changes should only be logged when a high
level of debugging is enabled.
Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
---
drivers/net/wireless/rtlwifi/cam.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/cam.c b/drivers/net/wireless/rtlwifi/cam.c
index 3ef870d..6e64792 100644
--- a/drivers/net/wireless/rtlwifi/cam.c
+++ b/drivers/net/wireless/rtlwifi/cam.c
@@ -406,7 +406,7 @@ u8 rtl_cam_get_free_entry(struct ieee80211_hw *hw, struct ieee80211_sta *sta,
}
}
if (found) {
- RT_TRACE(rtlpriv, COMP_SEC, DBG_EMERG,
+ RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG,
"key_index=%d,cam_bitmap: 0x%x entry_idx=%d\n",
key_index, rtlpriv->sec.cam_bitmap, entry_idx);
return entry_idx;
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached
From: Daniel Borkmann @ 2015-01-23 17:10 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: Sun Paul, linux-sctp, netdev, linux-kernel, tuexen
In-Reply-To: <54C27137.5010405@gmail.com>
On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
>> On 01/23/2015 11:25 AM, Sun Paul wrote:
>> ...
>>> I would like to check the behave in LKSCTP.
>>>
>>> we are running DIAMETER message over SCTP, and we have set the
>>> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>>>
>>> We noticed that when remote peer have retry to send the same request
>>> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
>>> "association exceeded its max_retrans count".
>>>
>>> We would like to know whether this is the correct behavior? is there
>>> any other option that we can alter in order to avoid the ABORT chunk
>>> being sent?
>>
>> I don't recall the RFC saying to send an ABORT, but let me double
>> check in the mean time.
>
> The RFC is silent on the matter. The abort got added in 3.8 so
> it's been there for a while.
I see, commit de4594a51c90 ("sctp: send abort chunk when max_retrans
exceeded") added the behaviour.
>> Hmm, untested, but could you try something like that?
>>
>> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
>> index fef2acd..5ce198d 100644
>> --- a/net/sctp/sm_sideeffect.c
>> +++ b/net/sctp/sm_sideeffect.c
>> @@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
>> sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
>> SCTP_ULPEVENT(event));
>>
>> - if (asoc->overall_error_count >= asoc->max_retrans) {
>> + if (asoc->overall_error_count >= asoc->max_retrans &&
>> + error != SCTP_ERROR_NO_ERROR) {
>> abort = sctp_make_violation_max_retrans(asoc, chunk);
>> if (abort)
>> sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>
> This would pretty much stop all ABORTs due to excessive rtx. Might
> as well take the code out :).
>
> I was a bit concerned about this ABORT when it went in.
So effectively, if I understand the argument from the commit, the
assumption is that the ABORT would never reach the peer anyway, but
is a way for tcpdump users to see on the wire that rtx limit has
been exceeded and since there's not mentioned anything in the RFC
about this, it doesn't break it. Hm.
Sun Paul, what exactly broke in your scenario? Can you be more explicit?
Thanks,
Daniel
^ permalink raw reply
* Re: [RESEND, 1/2] wlcore: fix copy-paste bug: assign from src struct not dest
From: Kalle Valo @ 2015-01-23 17:07 UTC (permalink / raw)
To: Giel van Schijndel
Cc: linux-kernel, Giel van Schijndel, John W. Linville, Eliad Peller,
Arik Nemtsov, open list:TI WILINK WIRELES...,
open list:NETWORKING DRIVERS
In-Reply-To: <1420659525-22975-1-git-send-email-me@mortis.eu>
> Signed-off-by: Giel van Schijndel <me@mortis.eu>
> Reported-at: http://www.viva64.com/en/b/0299/
Thanks, applied to wireless-drivers-next.git.
Kalle Valo
^ permalink raw reply
* Re: [PATCH net-next 0/3] openvswitch: Add STT support.
From: Tom Herbert @ 2015-01-23 16:58 UTC (permalink / raw)
To: Pravin B Shelar; +Cc: David Miller, Linux Netdev List
In-Reply-To: <1421785536-19793-1-git-send-email-pshelar@nicira.com>
On Tue, Jan 20, 2015 at 12:25 PM, Pravin B Shelar <pshelar@nicira.com> wrote:
> Following patch series adds support for Stateless Transport
> Tunneling protocol.
> STT uses TCP segmentation offload available in most of NIC. On
> packet xmit STT driver appends STT header along with TCP header
> to the packet. For GSO packet GSO parameters are set according
> to tunnel configuration and packet is handed over to networking
> stack. This allows use of segmentation offload available in NICs
>
> Netperf unidirectional test gives ~9.4 Gbits/s performance on 10Gbit
> NIC with 1500 byte MTU with two TCP streams.
>
The reason you're able to get 9.4 Gbit/s with an L2 encapsulation
using STT is that it has less protocol overhead per packet when doing
segmentation compared to VXLAN (without segmentation STT packets will
have more overhead than VXLAN).
A VXLAN packet with TCP/IP has headers
IP|UDP|VXLAN|Ethernet|IP|TCP+options. Assuming TCP is stuffed with
options, this is 20+8+8+16+20+40=112 bytes, or 7.4% MTU. Each STT
segment created in GSO, other than the first, has just IP|TCP headers
which is 20+20=40 bytes or 2.6% MTU. So this explains throughput
differences between VXLAN and STT.
With some clever coding, this same effect can be achieved using a UDP
encapsulation protocol that allows options. Suppose we create a new
option that we'll call Remote Segmentation Offload (RSO). The option
contains sequence number, fragment number that is coming from TCP
header in STT. We'll give this option eight bytes, and we'll also need
Remote Checksum Offload (therefore UDP checksum enabled). The headers
for each segment (except first) in GUE would then be something like
IP|UDP|GUE+options, with overhead 20+8+4+16 bytes=48 bytes, or 3.2%
MTU.
Like STT, RSO requires reassembly. Most of this can probably be done
in GRO. Processing is also a little cheaper since we don't need to
walk down as many protocol layers.
Conceptually, in the presence of packet loss we can recover any
segments as long as the first one in the chain that contains the full
set of headers isn't lost. If the first one is lost, then everything
in that block is lost since there's not enough context for reassembly
(I suspect this is also true in STT).
Tom
> The protocol is documented at
> http://www.ietf.org/archive/id/draft-davie-stt-06.txt
>
> I will send out OVS userspace patch on ovs-dev mailing list.
>
> Pravin B Shelar (3):
> skbuff: Add skb_list_linearize()
> net: Add STT tunneling protocol.
> openvswitch: Add support for STT tunneling.
>
> include/linux/skbuff.h | 2 +
> include/net/stt.h | 55 ++
> include/uapi/linux/openvswitch.h | 1 +
> net/core/skbuff.c | 35 +
> net/ipv4/Kconfig | 11 +
> net/ipv4/Makefile | 1 +
> net/ipv4/stt.c | 1386 ++++++++++++++++++++++++++++++++++++++
> net/openvswitch/Kconfig | 10 +
> net/openvswitch/Makefile | 1 +
> net/openvswitch/vport-stt.c | 214 ++++++
> 10 files changed, 1716 insertions(+)
> create mode 100644 include/net/stt.h
> create mode 100644 net/ipv4/stt.c
> create mode 100644 net/openvswitch/vport-stt.c
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: PHYless ethernet switch MAC-MAC serdes connection
From: Vijay Katoch @ 2015-01-23 16:49 UTC (permalink / raw)
To: netdev
In-Reply-To: <loom.20150121T075010-767@post.gmane.org>
It seems this behaviour is normal when assigning ip address to 3 devices
and all of them are 'up'.
When I examined packets using wireshark, correct packets are received on
other host.
I resolved the issue of interface that is configured first controlling
transmission, by running ifplugd daemon. So if cable connected to port
which was configured first is unplugged, that interface will go down,
allowing any of the other to transmit.
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: John Fastabend @ 2015-01-23 16:42 UTC (permalink / raw)
To: Thomas Graf
Cc: Jamal Hadi Salim, Pablo Neira Ayuso, simon.horman, sfeldma,
netdev, davem, gerlitz.or, andy, ast, Jiri Pirko
In-Reply-To: <20150123104932.GG25797@casper.infradead.org>
On 01/23/2015 02:49 AM, Thomas Graf wrote:
> On 01/22/15 at 08:58am, John Fastabend wrote:
>> In response to Pablo's observation,
>>
>> Correct this is fully exposed to user space, but it is also self
>> contained inside the API meaning I can learn when to use it and what it
>> does by looking at the other operations tables the table graph and
>> supported headers. The assumption I am making that is not in the API
>> explicitly yet. Is that actions named "set_field_name" perform the
>> set operation on that field. We can and plan to extend the API to make
>> this assumption explicit in the API.
>
> OK. I think it's this assumption that is not explicitly in the API yet
> that causes confusion. Making it explicit would definitely help. Do
> we even need the driver to declare get/set operations at all? Can we
> just have the driver expose the field and the API takes care of
> providing get/set actions?
>
>> Even though its a detail of the rocker world its easy enough for a
>> program on top of the API to learn how it works.
>>
>> So in the rocker switch case if I want to rewrite an eth_dst adress I
>> have a couple choices. I can set the group_id in one of the tables
>> that support setting the group_id and then do the rewrite in one of the
>> tables that supports matching on group_id and setting the eth_dst mac.
>> The "choice" I make is a policy IMO and I don't want to hard code logic
>> in the kernel that picks tables and decides things like what should I
>> do if table x is full but table y could also be used should I overflow
>> into table y? Or is table y reserved for some other network function?
>> etc.
>
> Agreed. It might make sense to declare such fields as general purpose
> metadata or have some kind of field class which describes the nature
> of the field: { register, protocol-field, configuration, ... }
>
>> There are some actions and metadata though that _need_ to be
>> standardized. These are the metadata that is used outside the API. For
>> example ingress_port is metadata that is set outside the tables.
>> Similarly set_egress_port and set_egress_queue provide the forwarding
>> and queueing fields. No matter how hard you look at the model from the
>> API you can not learn how these are used.
>
> Agreed. I assume we would implement a tun_dst the same standardized way.
>
>>> What would a rocker group map to in the tc world?
>>
>> In the 'tc' world I would guess the easiest thing to do is simply bind
>> a 'tc' qdisc to the ACL table. It seems a good first approximation of
>> how to make this work. But the rocker world doesn't yet have any QOS so
>> it makes it difficult to "offload" anything but the fifo qdiscs.
>
> Right. I was asking as tc will have the same difficulty if it wishes
> to classify based on rocker groups or other general purpose hardware
> metadata fields. We can either supoprt them by describing them and
> allow learning of such fields or ignore them.
>
>>>> I see this as a gaping hole
>>>> for vendor SDKs with their own definitions of their own hardware that
>>>> doesnt work with anyone else. i.e it seems to standardize proprietary
>>>> interfaces. Maybe thats what Pablo is alluding to.
>>>
>>> I will be the first to root for rejection if such patches appear.
>>>
>>
>> Is it problematic if users define some unique header here and then
>> provide actions to set/pop/push/get operations on it?
couple additional comments I wanted to add here,
>
> I have no problem with unique headers but we have to ensure that a
> field with identical purpose or same logical meaning is represented in
> the same way by all drivers. If a driver introduces a new field it
> must consider that other drivers will need/want to use it as well.
> I guess/hope this is obvious though ;-)
>
Yep, so my thought here is as if_flow_common.h builds up a list of
headers then a driver writer can go into their pipeline and "click" on
the headers they support to define the devices parse graph. Because
pkt headers are described using length/offset/mask types its always
clear what an ethernet header is and what a ip header is. There really
is no way to define/represent an ip header differently. If a driver
writer puts in there own definition and doesn't use our if_flow_common
definition it will be duplicate code and we should squash it. But for a
consumer of the API it will be the _same_ header assuming there are no
bugs in the definition.
> I agree that if chip A has 8 general purpose registers and chip B has
> 32 of them then it doesn't matter how they are called. What matters is
> that they are declared as such to API users.
You could add a flag to the field type to indicate explicitly it is
metadata or a register but I've not found any need for it. I leave
it out of the pkt header graph and then let consumers note these
are metadata fields that can be used. If we need this to be explicit
its easy enough to add a flags field.
>
> Actions must obviously be standardized as your proposal already does
> by exposing push_vlan, pop_vlan, etc.
>
At minimum you need a standardized a primitive set that you can use to
define other actions. push/pop/set/get can be standardized. It may be
that hardware has more complicated actions that act as an atomic actions
to do a entire list of actions, set some fields + pop headers for
example. Consumers can sort out how these actions work by looking at
the list of primitives. Its an optimization problem then for users of
the API to "know" they have applied a set of actions that the hardware
could actually do in a single action.
Note this set of patches 00/12 did not define the primitives or use it
in the action definitions. I think it is follow on work. Besides rocker
doesn't have any of these type of actions yet. A 'route' action might
be described using primitives for example.
.John
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH V2 for 3.19 0/7] Fixes for rtl8192ee
From: Larry Finger @ 2015-01-23 16:40 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless, netdev,
"troy_tan@realsil.com.cn >> 谭杭波"
In-Reply-To: <873871msc7.fsf@kamboji.qca.qualcomm.com>
On 01/23/2015 09:26 AM, Kalle Valo wrote:
> Larry Finger <Larry.Finger@lwfinger.net> writes:
>
>> This is V2 of the patches for rtl8192ee to be applied to 3.19. They replace
>> all the patches submitted under the title '[PATCH for 3.19 0/3] rtlwifi:
>> Various updates/fixes". All are marked for backporting to 3.18.
>>
>> The first of these removes a logging statement that is no longer needed.
>>
>> Patches 1-6 are relatively small and should not be a problem for 3.19.
>> Patch 7 is quite a bit larger, and adds two new routines to detect
>> DMA stalls. I will understand if you want to defer that to -next; however,
>> it does fix a serious problem.
>
> -rc6 is most likely released on Sunday, I cannot send six patches this
> late in the cycle unless our inboxes are filling of bug reports. As my
> inbox seems to be pretty empty about rtlwifi problems can you give more
> background why you think it's important to get these to 3.19? Are these
> all regressions from 3.18 or older bugs which just got fixed now?
>
>> rtlwifi: Remove logging statement that is no longer needed
>
> I think this is ok.
>
>> rtlwifi: rtl8192ee: Fix adhoc fail
>
> Ad-Hoc mode is not that popular, IMHO this can easily wait for -next.
>
>> rtlwifi: rtl8192ee: Fix problems with calculating free space in FIFO
>> rtlwifi: rtl8192ee: Fix handling of new style descriptors
>> rtlwifi: rtl8192ee: Fix TX hang due to failure to update TX write
>> point
>> rtlwifi: rtl8192ee: Fix parsing of received packet
>> rtlwifi: rtl8192ee: Fix DMA stalls
>
> For -rc1 or -rc2 these would have been ok, but without really good
> justifications getting these into -rc7 is difficult.
>
> But the patches itself are create, huge improvement compared to v1.
Kalle,
It is too bad that it took so long to get these ready. I think the reason that
there are not a lot of bug reports is because the complaints are all in the
GitHub issues for the rtlwifi_new repo, or with Ubuntu. If there are any that
get filed against Bugzilla, I will refer them to that repo.
Driver rtl8192ee was new in 3.18. There had been a previous version in staging,
but it did not get a lot of usage. I'm not sure if the additional usage after
3.18 was due to the driver being in the regular tree, or if vendors started
using the chips, but the problem reports started arriving. All these bugs have
been part of rtl8192ee since it has been in the kernel, thus they are hard to
categorize as regressions.
Push all 7 into -next so that they will be in 3.20. If you think it to be
prudent, please leave the Cc for stable. That way 3.18 and 3.19 will eventually
get the fixes.
Thanks,
Larry
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: Jiri Pirko @ 2015-01-23 16:16 UTC (permalink / raw)
To: Thomas Graf
Cc: John Fastabend, Jamal Hadi Salim, Pablo Neira Ayuso, simon.horman,
sfeldma, netdev, davem, gerlitz.or, andy, ast
In-Reply-To: <20150123160058.GN25797@casper.infradead.org>
Fri, Jan 23, 2015 at 05:00:58PM CET, tgraf@suug.ch wrote:
>On 01/23/15 at 04:53pm, Jiri Pirko wrote:
>> Fri, Jan 23, 2015 at 04:34:55PM CET, john.fastabend@gmail.com wrote:
>> >What I don't have a lot of use for at the moment is an xflows that runs
>> >in software? Conceptually it sounds fine but why would I want to mirror
>> >hardware limitations into software? And if I make it completely generic
>> >it becomes u32 more or less. I could create an optimized version of the
>> >hardware dataplane in userspace which sits somewhere between u32 and the
>> >other classifiers on flexility and maybe gains some performance but I'm
>> >at a loss as to why this is useful. I would rather spend my time getting
>> >better performance out of u32 and dropping qdisc_lock completely then
>> >writing some partially useful filter for software.
>>
>> Well, even software implementation has limitations. Take ovs kernel
>> datapath as example. You can use your graphs to describe exactly what
>> ovs can handle. And after that you could use xflows api to set it up as
>> well as your rocker offload. That to me seems lie a very nice feature to
>> have.
>
>What is the value of this? The OVS kernel datapath is already built to
>fall back to user space if the kernel datapath does not support a
>specific feature.
As I wrote earlier, the value is that userspace can easily use single
xflows api to take care of all ways to handle flows (ovs kernel dp,
rocker, other device, u32 tc filter + actions, you name it)
my flow managing app
|
uspc |
--------|----------------------------------------------------
krnl |
tc xflows api
| | |
| | ---------------------------------------------------
| | |
| ------------------ other xflows backend
| |
ovs xflows backend rocker driver xflows backend
| |
ovs dp |
krnl |
----------------------------|--------------------------------
hw |
rocker switch
^ permalink raw reply
* Re: [RFC PATCH] net: ipv6: Make address flushing on ifdown optional
From: Brian Haley @ 2015-01-23 16:09 UTC (permalink / raw)
To: David Ahern, netdev; +Cc: hannes
In-Reply-To: <1421263039-96198-1-git-send-email-dsahern@gmail.com>
On 01/14/2015 02:17 PM, David Ahern wrote:
> Currently, ipv6 addresses are flushed when the interface is configured down:
>
> [root@f20 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
> [root@f20 ~]# ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> inet6 2000:11:1:1::1/64 scope global tentative
> valid_lft forever preferred_lft forever
> [root@f20 ~]# ip link set dev eth1 up
> [root@f20 ~]# ip link set dev eth1 down
> [root@f20 ~]# ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
>
> Add a new sysctl to make this behavior optional. Setting defaults to flush
> addresses to maintain backwards compatibility. When reset flushing is bypassed:
>
> [root@f20 ~]# echo 0 > /proc/sys/net/ipv6/conf/eth1/flush_addr_on_down
> [root@f20 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
> [root@f20 ~]# ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> inet6 2000:11:1:1::1/64 scope global tentative
> valid_lft forever preferred_lft forever
> [root@f20 ~]# ip link set dev eth1 up
> [root@f20 ~]# ip link set dev eth1 down
> [root@f20 ~]# ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> inet6 2000:11:1:1::1/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::4:11ff:fe22:3301/64 scope link
> valid_lft forever preferred_lft forever
I think this was brought up in a previous thread on this, but don't you have to
do DAD on these addresses once the interface comes back up? Some other system
could have come along, done DAD, succeeded, and is now using it. Or does the
use of this flag assume the user is Ok without doing DAD, and will deal with the
fallout?
-Brian
^ permalink raw reply
* Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached
From: Vlad Yasevich @ 2015-01-23 16:08 UTC (permalink / raw)
To: Sun Paul, linux-sctp, netdev, linux-kernel
In-Reply-To: <CAFXGft+fwo=8LJEG7h6uOpGciSo5f_dXjSx3sn67RZZp7jsYHw@mail.gmail.com>
On 01/23/2015 05:25 AM, Sun Paul wrote:
> Hi
>
> I would like to check the behave in LKSCTP.
>
> we are running DIAMETER message over SCTP, and we have set the
> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>
> We noticed that when remote peer have retry to send the same request
> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
> "association exceeded its max_retrans count".
>
> We would like to know whether this is the correct behavior? is there
> any other option that we can alter in order to avoid the ABORT chunk
> being sent?
>
Why do you not want ABORT to be sent? SCTP has attempted to retransmit
the data maximum allows times, and at this point it will terminate
the association. It sends an ABORT notifying the peer of this, but
most likely the peer is unreachable anyway.
Any message that a peer sends at this point will most likely result
in an ABORT to be send back or an association restart. Might
as well start fresh.
-vlad
> Thanks
>
> PS
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: John Fastabend @ 2015-01-23 16:08 UTC (permalink / raw)
To: Thomas Graf
Cc: Jiri Pirko, Jamal Hadi Salim, Pablo Neira Ayuso, simon.horman,
sfeldma, netdev, davem, gerlitz.or, andy, ast
In-Reply-To: <20150123160058.GN25797@casper.infradead.org>
On 01/23/2015 08:00 AM, Thomas Graf wrote:
> On 01/23/15 at 04:53pm, Jiri Pirko wrote:
>> Fri, Jan 23, 2015 at 04:34:55PM CET, john.fastabend@gmail.com wrote:
>>> What I don't have a lot of use for at the moment is an xflows that runs
>>> in software? Conceptually it sounds fine but why would I want to mirror
>>> hardware limitations into software? And if I make it completely generic
>>> it becomes u32 more or less. I could create an optimized version of the
>>> hardware dataplane in userspace which sits somewhere between u32 and the
>>> other classifiers on flexility and maybe gains some performance but I'm
>>> at a loss as to why this is useful. I would rather spend my time getting
>>> better performance out of u32 and dropping qdisc_lock completely then
>>> writing some partially useful filter for software.
>>
>> Well, even software implementation has limitations. Take ovs kernel
>> datapath as example. You can use your graphs to describe exactly what
>> ovs can handle. And after that you could use xflows api to set it up as
>> well as your rocker offload. That to me seems lie a very nice feature to
>> have.
>
> What is the value of this? The OVS kernel datapath is already built to
> fall back to user space if the kernel datapath does not support a
> specific feature.
>
I might be reaching.. but one advantage of something like this API is
the headers are not pre-defined nor are the actions. Coupled with eBPF
or a generic parser (think optimized u32) you would provide the ability
to configure the OVS fields in use and the actions being supported. Also
I haven't thought about it as much but if you had programmable hardware
and/or software you could create the set operations for headers, tables,
actions. I've done some work on the set tables because its relatively
common on existing hardware. Its on github in the flow tool and the
user space tester flowd.
I think the OVS folks have been thinking along these lines. Of course
your still bound by OF1.x at the moment.
.John
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH net-next v3 2/5] swdevice: add new api to set and del bridge port attributes
From: Jiri Pirko @ 2015-01-23 16:06 UTC (permalink / raw)
To: roopa
Cc: sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen, vyasevic,
ronen.arad, netdev, davem, shm, gospo
In-Reply-To: <54C26FC1.70605@cumulusnetworks.com>
Fri, Jan 23, 2015 at 04:58:57PM CET, roopa@cumulusnetworks.com wrote:
>On 1/23/15, 2:41 AM, Jiri Pirko wrote:
>
><snip..>
>>
>>diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
>>index d162b21..bf0be98 100644
>>--- a/net/switchdev/switchdev.c
>>+++ b/net/switchdev/switchdev.c
>>@@ -50,3 +50,73 @@ int netdev_switch_port_stp_update(struct net_device *dev, u8 state)
>> return ops->ndo_switch_port_stp_update(dev, state);
>>}
>>EXPORT_SYMBOL(netdev_switch_port_stp_update);
>>+
>>+/**
>>+ * netdev_switch_port_bridge_setlink - Notify switch device port of bridge
>>+ * port attributes
>>+ *
>>+ * @dev: port device
>>+ * @nlh: netlink msg with bridge port attributes
>>+ *
>>+ * Notify switch device port of bridge port attributes
>>+ */
>>+int netdev_switch_port_bridge_setlink(struct net_device *dev,
>>+ struct nlmsghdr *nlh, u16 flags)
>>+{
>>+ const struct net_device_ops *ops = dev->netdev_ops;
>>+ struct net_device *lower_dev;
>>+ struct list_head *iter;
>>+ int ret = 0, err = 0;
>>+
>>+ if (!(dev->features & NETIF_F_HW_NETFUNC_OFFLOAD))
>>+ return err;
>>+
>>+ if (ops->ndo_bridge_setlink) {
>>+ WARN_ON(!ops->ndo_switch_parent_id_get);
>>+ return ops->ndo_bridge_setlink(dev, nlh, flags);
>>+ }
>>+
>>+ netdev_for_each_lower_dev(dev, lower_dev, iter) {
>>+ err = netdev_switch_port_bridge_setlink(lower_dev, nlh, flags);
>>+ if (err)
>>+ ret = err;
>>+ }
>>+
>>+ return ret;
>>+}
>>+EXPORT_SYMBOL(netdev_switch_port_bridge_setlink);
>>+
>>+/**
>>+ * netdev_switch_port_bridge_dellink - Notify switch device port of bridge
>>+ * attribute delete
>>+ *
>>+ * @dev: port device
>>+ * @nlh: netlink msg with bridge port attributes
>>+ *
>>+ * Notify switch device port of bridge port attribute delete
>>+ */
>>+int netdev_switch_port_bridge_dellink(struct net_device *dev,
>>+ struct nlmsghdr *nlh, u16 flags)
>>+{
>>+ const struct net_device_ops *ops = dev->netdev_ops;
>>+ struct net_device *lower_dev;
>>+ struct list_head *iter;
>>+ int ret = 0, err = 0;
>>+
>>+ if (!(dev->features & NETIF_F_HW_NETFUNC_OFFLOAD))
>>+ return err;
>>+
>>+ if (ops->ndo_bridge_dellink) {
>>+ WARN_ON(!ops->ndo_switch_parent_id_get);
>>+ return ops->ndo_bridge_dellink(dev, nlh, flags);
>>+ }
>>+
>>+ netdev_for_each_lower_dev(dev, lower_dev, iter) {
>>+ err = netdev_switch_port_bridge_dellink(lower_dev, nlh, flags);
>>+ if (err)
>>+ ret = err;
>>+ }
>>+
>>+ return ret;
>>+}
>>+EXPORT_SYMBOL(netdev_switch_port_bridge_dellink);
>>--
>>1.7.10.4
>>
>>Is there any other place, other than bridge code, this functions are
>>suppored to be called from?
>No other place today. Its usually the master that implements
>ndo_bridge_setlink/dellink.
>
>>If not, which I consider likely, it would
>>make more sense to me to:
>>
>>- move netdev_for_each_lower_dev iterations directly to bridge code
>>- let the masters (bond, team, ..) implement ndo_bridge_*link and do
>> the traversing there (can be in a form of pre-prepared default
>> ndo callback (ndo_dflt_netdev_switch_port_bridge_*link)
>But, i am still not understanding why i would modify bond, team and other
>slaves
Well, that is the usual way to propagate ndo calls. People are used to
this. It is visible right away in bonding/other code that is propagated
some ndo call to slaves. With your code, that is somehow hidden and only
dependent on NETIF_F_HW_NETFUNC_OFFLOAD flag.
Note that there are only couple of "master drivers" (for this, most likely
only bond and team modifications are needed).
>to offload bridge attributes. They could independently do so in the future if
>they
>want to do something more than what this default api provides.
>The api's setlink/dellink provided by this patch are the default api's.
>The drivers can override them if needed in the future (which aligns with what
>you want as well).
>
>Thanks,
>Roopa
>
>
>
>
^ permalink raw reply
* Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached
From: Vlad Yasevich @ 2015-01-23 16:05 UTC (permalink / raw)
To: Daniel Borkmann, Sun Paul; +Cc: linux-sctp, netdev, linux-kernel
In-Reply-To: <54C23581.9060809@redhat.com>
On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
> Hi,
>
> On 01/23/2015 11:25 AM, Sun Paul wrote:
> ...
>> I would like to check the behave in LKSCTP.
>>
>> we are running DIAMETER message over SCTP, and we have set the
>> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>>
>> We noticed that when remote peer have retry to send the same request
>> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
>> "association exceeded its max_retrans count".
>>
>> We would like to know whether this is the correct behavior? is there
>> any other option that we can alter in order to avoid the ABORT chunk
>> being sent?
>
> I don't recall the RFC saying to send an ABORT, but let me double
> check in the mean time.
The RFC is silent on the matter. The abort got added in 3.8 so
it's been there for a while.
>
> Hmm, untested, but could you try something like that?
>
> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
> index fef2acd..5ce198d 100644
> --- a/net/sctp/sm_sideeffect.c
> +++ b/net/sctp/sm_sideeffect.c
> @@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
> sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
> SCTP_ULPEVENT(event));
>
> - if (asoc->overall_error_count >= asoc->max_retrans) {
> + if (asoc->overall_error_count >= asoc->max_retrans &&
> + error != SCTP_ERROR_NO_ERROR) {
> abort = sctp_make_violation_max_retrans(asoc, chunk);
> if (abort)
> sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
This would pretty much stop all ABORTs due to excessive rtx. Might
as well take the code out :).
I was a bit concerned about this ABORT when it went in.
-vlad
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: Thomas Graf @ 2015-01-23 16:00 UTC (permalink / raw)
To: Jiri Pirko
Cc: John Fastabend, Jamal Hadi Salim, Pablo Neira Ayuso, simon.horman,
sfeldma, netdev, davem, gerlitz.or, andy, ast
In-Reply-To: <20150123155332.GJ2065@nanopsycho.orion>
On 01/23/15 at 04:53pm, Jiri Pirko wrote:
> Fri, Jan 23, 2015 at 04:34:55PM CET, john.fastabend@gmail.com wrote:
> >What I don't have a lot of use for at the moment is an xflows that runs
> >in software? Conceptually it sounds fine but why would I want to mirror
> >hardware limitations into software? And if I make it completely generic
> >it becomes u32 more or less. I could create an optimized version of the
> >hardware dataplane in userspace which sits somewhere between u32 and the
> >other classifiers on flexility and maybe gains some performance but I'm
> >at a loss as to why this is useful. I would rather spend my time getting
> >better performance out of u32 and dropping qdisc_lock completely then
> >writing some partially useful filter for software.
>
> Well, even software implementation has limitations. Take ovs kernel
> datapath as example. You can use your graphs to describe exactly what
> ovs can handle. And after that you could use xflows api to set it up as
> well as your rocker offload. That to me seems lie a very nice feature to
> have.
What is the value of this? The OVS kernel datapath is already built to
fall back to user space if the kernel datapath does not support a
specific feature.
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: Jiri Pirko @ 2015-01-23 16:00 UTC (permalink / raw)
To: Thomas Graf
Cc: Jamal Hadi Salim, Pablo Neira Ayuso, John Fastabend, simon.horman,
sfeldma, netdev, davem, gerlitz.or, andy, ast
In-Reply-To: <20150123154949.GM25797@casper.infradead.org>
Fri, Jan 23, 2015 at 04:49:49PM CET, tgraf@suug.ch wrote:
>On 01/23/15 at 04:25pm, Jiri Pirko wrote:
>> Fri, Jan 23, 2015 at 03:07:24PM CET, tgraf@suug.ch wrote:
>> >How does John's API fit into this? How would you expose capabilities
>> >through xflows? How would it differ from what John proposes?
>>
>> This certainly need more thinking. The capabilities could be exposed
>> either by separate a genl api (like in this version) or directly via TC
>> netlink iface (RTM_GETTFILTERCAP, RTM_GETACTIONCAP). The insides of the
>> message can stay the same. I like the second way better.
>
>OK. Any particular reason why you like the tc integration better?
As I wrote earlier, that would provides us a single interface for flow
manipulation in both sw and hw. That is why I prefer tc here.
>
>> flow manipulation would happen as standard TC filters/actions manipulation.
>> Here, the Netlink messages could be also very similar to what John has now.
>
>I have one concern here: This would mean we put flow modifications
>under the rtnl lock which will have severe impact on the rate of
>flow modifications we can support. We need flow table modifications
>to continue being super fast.
I agree that is a problem. But I believe that can be resolved (have to
think about this some more).
>
>Parallel genetlink operations were introduced just for this.
>
>> Right. We have to either introduce some limitations for xflows to
>> disallow this or let the user to take care of this. But it's similar
>> problem as if you use tc with John's API or ovs with John's API.
>
>Agreed. It's a general problem with having multiple indepdent tools.
^ permalink raw reply
* Re: [PATCH net-next v3 3/5] bridge: offload bridge port attributes to switch asic if feature flag set
From: roopa @ 2015-01-23 15:59 UTC (permalink / raw)
To: Rosen, Rami
Cc: jiri@resnulli.us, sfeldma@gmail.com, jhs@mojatatu.com,
bcrl@kvack.org, tgraf@suug.ch, john.fastabend@gmail.com,
stephen@networkplumber.org, vyasevic@redhat.com, Arad, Ronen,
netdev@vger.kernel.org, davem@davemloft.net,
shm@cumulusnetworks.com, gospo@cumulusnetworks.com
In-Reply-To: <9B0331B6EBBD0E4684FBFAEDA55776F9189065DD@HASMSX110.ger.corp.intel.com>
On 1/23/15, 4:53 AM, Rosen, Rami wrote:
> Hi,
> There is another Linux Ethernet driver which defines the ndo_bridge_setlink() callback, which is not included in the patch. It is the
> Emulex ServerEngines' 10Gbps NIC (BladeEngine) (drivers/net/ethernet/emulex/benet).
> So once the CONFIG_BE2NET kernel config item is set, running make will emit a compile warning.
>
>
Thanks for catching this and your other comment. will fix them in the
next version.
^ permalink raw reply
* Re: [PATCH net-next v3 2/5] swdevice: add new api to set and del bridge port attributes
From: roopa @ 2015-01-23 15:58 UTC (permalink / raw)
To: Jiri Pirko
Cc: sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen, vyasevic,
ronen.arad, netdev, davem, shm, gospo
In-Reply-To: <20150123104127.GC2065@nanopsycho.orion>
On 1/23/15, 2:41 AM, Jiri Pirko wrote:
<snip..>
>
> diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
> index d162b21..bf0be98 100644
> --- a/net/switchdev/switchdev.c
> +++ b/net/switchdev/switchdev.c
> @@ -50,3 +50,73 @@ int netdev_switch_port_stp_update(struct net_device *dev, u8 state)
> return ops->ndo_switch_port_stp_update(dev, state);
> }
> EXPORT_SYMBOL(netdev_switch_port_stp_update);
> +
> +/**
> + * netdev_switch_port_bridge_setlink - Notify switch device port of bridge
> + * port attributes
> + *
> + * @dev: port device
> + * @nlh: netlink msg with bridge port attributes
> + *
> + * Notify switch device port of bridge port attributes
> + */
> +int netdev_switch_port_bridge_setlink(struct net_device *dev,
> + struct nlmsghdr *nlh, u16 flags)
> +{
> + const struct net_device_ops *ops = dev->netdev_ops;
> + struct net_device *lower_dev;
> + struct list_head *iter;
> + int ret = 0, err = 0;
> +
> + if (!(dev->features & NETIF_F_HW_NETFUNC_OFFLOAD))
> + return err;
> +
> + if (ops->ndo_bridge_setlink) {
> + WARN_ON(!ops->ndo_switch_parent_id_get);
> + return ops->ndo_bridge_setlink(dev, nlh, flags);
> + }
> +
> + netdev_for_each_lower_dev(dev, lower_dev, iter) {
> + err = netdev_switch_port_bridge_setlink(lower_dev, nlh, flags);
> + if (err)
> + ret = err;
> + }
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(netdev_switch_port_bridge_setlink);
> +
> +/**
> + * netdev_switch_port_bridge_dellink - Notify switch device port of bridge
> + * attribute delete
> + *
> + * @dev: port device
> + * @nlh: netlink msg with bridge port attributes
> + *
> + * Notify switch device port of bridge port attribute delete
> + */
> +int netdev_switch_port_bridge_dellink(struct net_device *dev,
> + struct nlmsghdr *nlh, u16 flags)
> +{
> + const struct net_device_ops *ops = dev->netdev_ops;
> + struct net_device *lower_dev;
> + struct list_head *iter;
> + int ret = 0, err = 0;
> +
> + if (!(dev->features & NETIF_F_HW_NETFUNC_OFFLOAD))
> + return err;
> +
> + if (ops->ndo_bridge_dellink) {
> + WARN_ON(!ops->ndo_switch_parent_id_get);
> + return ops->ndo_bridge_dellink(dev, nlh, flags);
> + }
> +
> + netdev_for_each_lower_dev(dev, lower_dev, iter) {
> + err = netdev_switch_port_bridge_dellink(lower_dev, nlh, flags);
> + if (err)
> + ret = err;
> + }
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(netdev_switch_port_bridge_dellink);
> --
> 1.7.10.4
>
> Is there any other place, other than bridge code, this functions are
> suppored to be called from?
No other place today. Its usually the master that implements
ndo_bridge_setlink/dellink.
> If not, which I consider likely, it would
> make more sense to me to:
>
> - move netdev_for_each_lower_dev iterations directly to bridge code
> - let the masters (bond, team, ..) implement ndo_bridge_*link and do
> the traversing there (can be in a form of pre-prepared default
> ndo callback (ndo_dflt_netdev_switch_port_bridge_*link)
But, i am still not understanding why i would modify bond, team and
other slaves
to offload bridge attributes. They could independently do so in the
future if they
want to do something more than what this default api provides.
The api's setlink/dellink provided by this patch are the default api's.
The drivers can override them if needed in the future (which aligns with
what you want as well).
Thanks,
Roopa
^ permalink raw reply
* Re: net_test_tools: add ipv6 support for kbench_mod
From: Shaohua Li @ 2015-01-23 15:58 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: David Miller, netdev, kafai
In-Reply-To: <54C21A9D.6080101@redhat.com>
On Fri, Jan 23, 2015 at 10:55:41AM +0100, Daniel Borkmann wrote:
> On 01/22/2015 11:12 PM, Shaohua Li wrote:
> ...
> >>>Yes, we need export the sysmbol for the test. Can we export the symbol?
> >>>or I can delete the route input test, which one do you prefer?
> >>
> >>There is no justification upstream to export that symbol since
> >>there are no modular users in-tree.
> >
> >I changed it to do the ip6_route_input test optionally. If the test is
> >required, somebody should change the kernel to export it and define
> >HAVE_IP6_ROUTE_INPUT in the test module. I thought this is fine for a
> >test module. How do you think?
>
> See above, it can only be changed/exported from the kernel as long as
> there is an in-tree module making use of it.
Yes, I mean if I want to test it, I export the symbol in my test kernel,
not for upstream.
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: Jiri Pirko @ 2015-01-23 15:56 UTC (permalink / raw)
To: John Fastabend
Cc: Thomas Graf, Jamal Hadi Salim, Pablo Neira Ayuso, simon.horman,
sfeldma, netdev, davem, gerlitz.or, andy, ast
In-Reply-To: <54C26C34.2000309@gmail.com>
Fri, Jan 23, 2015 at 04:43:48PM CET, john.fastabend@gmail.com wrote:
>On 01/23/2015 07:25 AM, Jiri Pirko wrote:
>>Fri, Jan 23, 2015 at 03:07:24PM CET, tgraf@suug.ch wrote:
>>>On 01/23/15 at 02:43pm, Jiri Pirko wrote:
>>>>Fri, Jan 23, 2015 at 01:28:38PM CET, tgraf@suug.ch wrote:
>>>>>If I understand this correctly then you propose to do the decision on
>>>>>whether to implement a flow in software or offload it to hardware in the
>>>>>xflows classifier and action. I had exactly the same architecture in mind
>>>>>initially when I first approached this and wanted to offload OVS
>>>>>datapath flows transparently to hardware.
>>>>
>>>>Think about xflows as an iface to multiple backends, some sw and some hw.
>>>>User will be able to specify which backed he wants to use for particular
>>>>"commands".
>>>>
>>>>So for example, ovs kernel datapath module will implement an xflows
>>>>backend and register it as "ovsdp". Rocker will implement another xflows
>>>>backend and register it as "rockerdp". Then, ovs userspace will use xflows
>>>>api to setup both backends independently, but using the same xflows api.
>>>>
>>>>It is still up to userspace to decide what should be put where (what
>>>>backend to use).
>>>
>>>OK, sounds good so far. Although we can't completely ditch the existing
>>>genl based OVS flow API for obvious backwards compatibility reasons ;-)
>>
>>Sure.
>
>Replied to the other thread before seeing this, but some comments.
>
>>
>>>
>>>How does John's API fit into this? How would you expose capabilities
>>>through xflows? How would it differ from what John proposes?
>>
>>This certainly need more thinking. The capabilities could be exposed
>>either by separate a genl api (like in this version) or directly via TC
>>netlink iface (RTM_GETTFILTERCAP, RTM_GETACTIONCAP). The insides of the
>>message can stay the same. I like the second way better.
>>
>
>For what its worth I started this route when I did the flow API before
>ditching it and going to its own netlink family.
>
>>flow manipulation would happen as standard TC filters/actions manipulation.
>>Here, the Netlink messages could be also very similar to what John has now.
>>
>
>In fact I think they are almost the same ;) I don't mind doing the
>embedding as long as there is some sort of plan for how to attach
>filters to hardware. This is where I got stuck. I think you need
>a new attach point in the hardware. See my other reply.
The special "offload" qdisc of some sort sound a good way to me.
>
>>
>>>
>>>Since this would be a regular tc classifier I assume it could be
>>>attached to any tc class and interface and then combined with other
>>>classifiers which OVS would not be aware of. How do you intend to
>>>resolve such conflicts?
>>>
>>>Example:
>>>eth0:
>>> ingress qdisc:
>>> cls prio 20 u32 match [...]
>>> cls prio 10 xflows [...]
>>>
>>>If xflows offloads to hardware, the u32 classifier with higher
>>>priority is hidden unintentionally.
>>
>>
>>Right. We have to either introduce some limitations for xflows to
>>disallow this or let the user to take care of this. But it's similar
>>problem as if you use tc with John's API or ovs with John's API.
>>
>
>But with the current API its clear that the rules managed by the
>Flow API are in front of 'tc' and 'ovs' on ingress. Just the same
>as it is clear 'tc' ingress rules are walked before 'ovs' ingress
>rules. On egress it is similarly clear that 'ovs' does a forward
>rule to a netdev, then 'tc' fiters+qdisc is run, and finally the
>hardware flow api is hit.
Seems like this would be resolved by the separe "offload" qdisc.
>
>I also think it is clear that when a packet never enters the software
>dataplane _only_ the hardware dataplane rules are used namely the
>entries in the Flow API.
>
>The cases I've been experimenting with using Flow API it is clear
>on the priority and what rules are being used by looking at counters
>and "knowing" the above pipeline mode.
>
>Although as I type this I think a picture would help and some
>documentation.
>
>.John
>
>
>--
>John Fastabend Intel Corporation
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: Jiri Pirko @ 2015-01-23 15:53 UTC (permalink / raw)
To: John Fastabend
Cc: Thomas Graf, Jamal Hadi Salim, Pablo Neira Ayuso, simon.horman,
sfeldma, netdev, davem, gerlitz.or, andy, ast
In-Reply-To: <54C26A1F.6060603@gmail.com>
Fri, Jan 23, 2015 at 04:34:55PM CET, john.fastabend@gmail.com wrote:
>On 01/23/2015 06:07 AM, Thomas Graf wrote:
>>On 01/23/15 at 02:43pm, Jiri Pirko wrote:
>>>Fri, Jan 23, 2015 at 01:28:38PM CET, tgraf@suug.ch wrote:
>>>>If I understand this correctly then you propose to do the decision on
>>>>whether to implement a flow in software or offload it to hardware in the
>>>>xflows classifier and action. I had exactly the same architecture in mind
>>>>initially when I first approached this and wanted to offload OVS
>>>>datapath flows transparently to hardware.
>>>
>>>Think about xflows as an iface to multiple backends, some sw and some hw.
>>>User will be able to specify which backed he wants to use for particular
>>>"commands".
>>>
>>>So for example, ovs kernel datapath module will implement an xflows
>>>backend and register it as "ovsdp". Rocker will implement another xflows
>>>backend and register it as "rockerdp". Then, ovs userspace will use xflows
>>>api to setup both backends independently, but using the same xflows api.
>>>
>>>It is still up to userspace to decide what should be put where (what
>>>backend to use).
>>
>>OK, sounds good so far. Although we can't completely ditch the existing
>>genl based OVS flow API for obvious backwards compatibility reasons ;-)
>>
>>How does John's API fit into this? How would you expose capabilities
>>through xflows? How would it differ from what John proposes?
>>
>>Since this would be a regular tc classifier I assume it could be
>>attached to any tc class and interface and then combined with other
>>classifiers which OVS would not be aware of. How do you intend to
>>resolve such conflicts?
>>
>>Example:
>> eth0:
>> ingress qdisc:
>> cls prio 20 u32 match [...]
>> cls prio 10 xflows [...]
>>
>>If xflows offloads to hardware, the u32 classifier with higher
>>priority is hidden unintentionally.
>>
>
>I thought about this at length. And I'm not opposed to pulling my API
>into a 'tc classifier' but I its not 100% clear to me the reason it
>helps.
>
>First 'tc' infrastructure doesn't have any classifier that would map
>well to this today so you are talking about a new classifier looks like
>Jiri is calling it xflows. This is fine.
>
>Now 'xflows' needs to implement the same get operations that exist in
>this flow API otherwise writing meaningful policies as Thomas points out
>is crude at best. So this tc classifier supports 'get headers',
>'get actions', and 'get tables' and then there associated graphs. All
>good so far. This is just an embedding of the existing API in the 'tc'
>netlink family. I've never had any issues with this. Finally you build
>up the 'get_flow' and 'set_flow' operations I still so no issue with
>this and its just an embedding of the existing API into a 'tc
>classifier'. My flow tool becomes one of the classifier tools.
>
>Now what should I attach my filter to? Typically we attach it to qdiscs
>today. But what does that mean for a switch device? I guess I need an
>_offloaded qdisc_? I don't want to run the same qdisc in my dataplane
>of the switch as I run on the ports going into/out of the sw dataplane.
>Similarly I don't want to run the same set of filters. So at this point
>I have a set of qdiscs per port to represent the switch dataplane and
>a set of qdiscs attached to the software dataplane. If people think this
>is worth doing lets do it. It may get you a nice way to manage QOS while
>your @ it.
Yes!
>
>At this point we have the above xflows filter that works on hardware and
>some qdisc abstraction to represent hardware great.
>
>What I don't have a lot of use for at the moment is an xflows that runs
>in software? Conceptually it sounds fine but why would I want to mirror
>hardware limitations into software? And if I make it completely generic
>it becomes u32 more or less. I could create an optimized version of the
>hardware dataplane in userspace which sits somewhere between u32 and the
>other classifiers on flexility and maybe gains some performance but I'm
>at a loss as to why this is useful. I would rather spend my time getting
>better performance out of u32 and dropping qdisc_lock completely then
>writing some partially useful filter for software.
Well, even software implementation has limitations. Take ovs kernel
datapath as example. You can use your graphs to describe exactly what
ovs can handle. And after that you could use xflows api to set it up as
well as your rocker offload. That to me seems lie a very nice feature to
have.
>
>My original conclusion was not to worry about embedding it inside 'tc'
>and I didn't mind having another netlink family but I'm not opposed to
>doing the embedding also if it helps someone, even if just resolves some
>cognitive dissonance.
>
>.John
>
>
>--
>John Fastabend Intel Corporation
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: Thomas Graf @ 2015-01-23 15:49 UTC (permalink / raw)
To: Jiri Pirko
Cc: Jamal Hadi Salim, Pablo Neira Ayuso, John Fastabend, simon.horman,
sfeldma, netdev, davem, gerlitz.or, andy, ast
In-Reply-To: <20150123152556.GG2065@nanopsycho.orion>
On 01/23/15 at 04:25pm, Jiri Pirko wrote:
> Fri, Jan 23, 2015 at 03:07:24PM CET, tgraf@suug.ch wrote:
> >How does John's API fit into this? How would you expose capabilities
> >through xflows? How would it differ from what John proposes?
>
> This certainly need more thinking. The capabilities could be exposed
> either by separate a genl api (like in this version) or directly via TC
> netlink iface (RTM_GETTFILTERCAP, RTM_GETACTIONCAP). The insides of the
> message can stay the same. I like the second way better.
OK. Any particular reason why you like the tc integration better?
> flow manipulation would happen as standard TC filters/actions manipulation.
> Here, the Netlink messages could be also very similar to what John has now.
I have one concern here: This would mean we put flow modifications
under the rtnl lock which will have severe impact on the rate of
flow modifications we can support. We need flow table modifications
to continue being super fast.
Parallel genetlink operations were introduced just for this.
> Right. We have to either introduce some limitations for xflows to
> disallow this or let the user to take care of this. But it's similar
> problem as if you use tc with John's API or ovs with John's API.
Agreed. It's a general problem with having multiple indepdent tools.
^ permalink raw reply
* Re: [PATCH net-next v3 1/5] netdev: introduce new NETIF_F_HW_NETFUNC_OFFLOAD feature flag for switch device offloads
From: roopa @ 2015-01-23 15:48 UTC (permalink / raw)
To: Jiri Pirko
Cc: sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen, vyasevic,
ronen.arad, netdev, davem, shm, gospo
In-Reply-To: <20150123094459.GA2065@nanopsycho.orion>
On 1/23/15, 1:44 AM, Jiri Pirko wrote:
> Fri, Jan 23, 2015 at 05:33:22AM CET, roopa@cumulusnetworks.com wrote:
>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>
>> This is a high level feature flag for all switch asic offloads
>>
>> switch drivers set this flag on switch ports. Logical devices like
>> bridge, bonds, vxlans can inherit this flag from their slaves/ports.
>>
>> The patch also adds the flag to NETIF_F_ONE_FOR_ALL, so that it gets
>> propagated to the upperdevices (bridges and bonds).
>>
>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>> ---
>> include/linux/netdev_features.h | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
>> index 8e30685..784a461 100644
>> --- a/include/linux/netdev_features.h
>> +++ b/include/linux/netdev_features.h
>> @@ -66,6 +66,7 @@ enum {
>> NETIF_F_HW_VLAN_STAG_FILTER_BIT,/* Receive filtering on VLAN STAGs */
>> NETIF_F_HW_L2FW_DOFFLOAD_BIT, /* Allow L2 Forwarding in Hardware */
>> NETIF_F_BUSY_POLL_BIT, /* Busy poll */
>> + NETIF_F_HW_NETFUNC_OFFLOAD_BIT, /* HW switch offload */
> How about rather "HW_DATAPATH_OFFLOAD"? Feels more accurate. By the
> name, I still cannot understand what NETFUNC should mean.
It was supposed to mean 'network function offload'. sure, will consider
HW_DATAPATH_OFFLOAD
or if anybody has other suggestions.
thanks.
>
>
>> /*
>> * Add your fresh new feature above and remember to update
>> @@ -124,6 +125,7 @@ enum {
>> #define NETIF_F_HW_VLAN_STAG_TX __NETIF_F(HW_VLAN_STAG_TX)
>> #define NETIF_F_HW_L2FW_DOFFLOAD __NETIF_F(HW_L2FW_DOFFLOAD)
>> #define NETIF_F_BUSY_POLL __NETIF_F(BUSY_POLL)
>> +#define NETIF_F_HW_NETFUNC_OFFLOAD __NETIF_F(HW_NETFUNC_OFFLOAD)
>>
>> /* Features valid for ethtool to change */
>> /* = all defined minus driver/device-class-related */
>> @@ -159,7 +161,9 @@ enum {
>> */
>> #define NETIF_F_ONE_FOR_ALL (NETIF_F_GSO_SOFTWARE | NETIF_F_GSO_ROBUST | \
>> NETIF_F_SG | NETIF_F_HIGHDMA | \
>> - NETIF_F_FRAGLIST | NETIF_F_VLAN_CHALLENGED)
>> + NETIF_F_FRAGLIST | NETIF_F_VLAN_CHALLENGED | \
>> + NETIF_F_HW_NETFUNC_OFFLOAD)
>> +
>> /*
>> * If one device doesn't support one of these features, then disable it
>> * for all in netdev_increment_features.
>> --
>> 1.7.10.4
>>
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: John Fastabend @ 2015-01-23 15:43 UTC (permalink / raw)
To: Jiri Pirko
Cc: Thomas Graf, Jamal Hadi Salim, Pablo Neira Ayuso, simon.horman,
sfeldma, netdev, davem, gerlitz.or, andy, ast
In-Reply-To: <20150123152556.GG2065@nanopsycho.orion>
On 01/23/2015 07:25 AM, Jiri Pirko wrote:
> Fri, Jan 23, 2015 at 03:07:24PM CET, tgraf@suug.ch wrote:
>> On 01/23/15 at 02:43pm, Jiri Pirko wrote:
>>> Fri, Jan 23, 2015 at 01:28:38PM CET, tgraf@suug.ch wrote:
>>>> If I understand this correctly then you propose to do the decision on
>>>> whether to implement a flow in software or offload it to hardware in the
>>>> xflows classifier and action. I had exactly the same architecture in mind
>>>> initially when I first approached this and wanted to offload OVS
>>>> datapath flows transparently to hardware.
>>>
>>> Think about xflows as an iface to multiple backends, some sw and some hw.
>>> User will be able to specify which backed he wants to use for particular
>>> "commands".
>>>
>>> So for example, ovs kernel datapath module will implement an xflows
>>> backend and register it as "ovsdp". Rocker will implement another xflows
>>> backend and register it as "rockerdp". Then, ovs userspace will use xflows
>>> api to setup both backends independently, but using the same xflows api.
>>>
>>> It is still up to userspace to decide what should be put where (what
>>> backend to use).
>>
>> OK, sounds good so far. Although we can't completely ditch the existing
>> genl based OVS flow API for obvious backwards compatibility reasons ;-)
>
> Sure.
Replied to the other thread before seeing this, but some comments.
>
>>
>> How does John's API fit into this? How would you expose capabilities
>> through xflows? How would it differ from what John proposes?
>
> This certainly need more thinking. The capabilities could be exposed
> either by separate a genl api (like in this version) or directly via TC
> netlink iface (RTM_GETTFILTERCAP, RTM_GETACTIONCAP). The insides of the
> message can stay the same. I like the second way better.
>
For what its worth I started this route when I did the flow API before
ditching it and going to its own netlink family.
> flow manipulation would happen as standard TC filters/actions manipulation.
> Here, the Netlink messages could be also very similar to what John has now.
>
In fact I think they are almost the same ;) I don't mind doing the
embedding as long as there is some sort of plan for how to attach
filters to hardware. This is where I got stuck. I think you need
a new attach point in the hardware. See my other reply.
>
>>
>> Since this would be a regular tc classifier I assume it could be
>> attached to any tc class and interface and then combined with other
>> classifiers which OVS would not be aware of. How do you intend to
>> resolve such conflicts?
>>
>> Example:
>> eth0:
>> ingress qdisc:
>> cls prio 20 u32 match [...]
>> cls prio 10 xflows [...]
>>
>> If xflows offloads to hardware, the u32 classifier with higher
>> priority is hidden unintentionally.
>
>
> Right. We have to either introduce some limitations for xflows to
> disallow this or let the user to take care of this. But it's similar
> problem as if you use tc with John's API or ovs with John's API.
>
But with the current API its clear that the rules managed by the
Flow API are in front of 'tc' and 'ovs' on ingress. Just the same
as it is clear 'tc' ingress rules are walked before 'ovs' ingress
rules. On egress it is similarly clear that 'ovs' does a forward
rule to a netdev, then 'tc' fiters+qdisc is run, and finally the
hardware flow api is hit.
I also think it is clear that when a packet never enters the software
dataplane _only_ the hardware dataplane rules are used namely the
entries in the Flow API.
The cases I've been experimenting with using Flow API it is clear
on the priority and what rules are being used by looking at counters
and "knowing" the above pipeline mode.
Although as I type this I think a picture would help and some
documentation.
.John
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH net-next v2] iproute2: bridge: support vlan range
From: roopa @ 2015-01-23 15:42 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, netdev, vyasevic, wkok, sfeldma
In-Reply-To: <20150122225106.569d4b92@urahara>
On 1/22/15, 10:51 PM, Stephen Hemminger wrote:
> On Thu, 22 Jan 2015 22:25:10 -0800
> roopa@cumulusnetworks.com wrote:
>
>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>
>> This patch adds vlan range support to bridge command
>> using the newly added vinfo flags BRIDGE_VLAN_INFO_RANGE_BEGIN and
>> BRIDGE_VLAN_INFO_RANGE_END.
>>
>> $bridge vlan show
>> port vlan ids
>> br0 1 PVID Egress Untagged
>>
>> dummy0 1 PVID Egress Untagged
>>
>> $bridge vlan add vid 10-15 dev dummy0
>> port vlan ids
>> br0 1 PVID Egress Untagged
>>
>> dummy0 1 PVID Egress Untagged
>> 10
>> 11
>> 12
>> 13
>> 14
>> 15
> Doing on vlan id per line gets ridiculous with 1000 vlan's
> how about something more compact?
yes, I was going to do that in a separate patch ...the kernel can dump
in ranges with the new flag.
I did not want to change default (current) show to print ranges.
Was planning on submitting a new patch with a new option. If you think
there are not many users out there today..
..and no fear of breaking users, i will include it in the current patch
in v3.
thanks.
^ permalink raw reply
* Re: [PATCH 1/7] net: wireless: wcn36xx: add wcn3620 chip type definition
From: Kalle Valo @ 2015-01-23 15:39 UTC (permalink / raw)
To: Andy Green
Cc: Eugene Krasnikov, wcn36xx, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev
In-Reply-To: <CAAfg0W4cns51+B_imf1jGWOmA0S8jqNFR+6epRxv8qqTgvBAgg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> writes:
> On 18 January 2015 at 22:17, Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
>> Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> writes:
n>>
>>> Convert the list of chip types to an enum, add the default
>>> UNKNOWN type and a type for WCN3620 chip
>>>
>>> Signed-off-by: Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>
>> Please just use "wcn36xx: ", you should drop "net: wireless: " entirely.
>
> OK.
>
> Can you help me understand what you'd like to see happen with the chip
> variant detection stuff?
I haven't looked at wcn36xx for a long time so I'm not really the right
person to answer. I'm more like a desk jockey now ;)
> There's a comment sent to one list only saying it might be preferable
> to keep the old detection code as the default. But there are no
> in-tree users of wcn36xx (mainly due to PIL not being in mainline, I
> guess).
>
> The old test's equivalence that AC == 3680 seems kind of weak to me
> and establishing the type must be passed in from platform code
> reflects the situation that there's no public way to detect the chip
> type from Qualcomm. In the second not-for-upstream series I use that
> to pass it in from DT, which is how it'd be normally used.
Please remember that the DT bindings document has to be acked by the
device-tree maintainers.
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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