* [PATCH net-next] bonding: handle more gso types
From: Eric Dumazet @ 2015-01-23 13:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Or Gerlitz
From: Eric Dumazet <edumazet@google.com>
In commit 5a7baa78851b ("bonding: Advertize vxlan offload features when
supported"), Or Gerlitz added support conditional vxlan offload.
In this patch I also add support for GRE, IPIP and SIT tunnels,
but we allow a bonding device to not require segmentation,
as it is always better to make this segmentation at the very last stage,
if a particular slave device requires it.
Tested:
ethtool -K bond0 tx-gre-segmentation off
super_netperf 50 --google-pacing-rate 30000000 -H 10.7.8.152 -l 15
7538.32
ethtool -K bond0 tx-gre-segmentation on
super_netperf 50 --google-pacing-rate 30000000 -H 10.7.8.152 -l 15
10200.5
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Or Gerlitz <ogerlitz@mellanox.com>
---
drivers/net/bonding/bond_main.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 0dceba1a2ba15f4706922a5423f680e7cd17ef77..1e837fceb3fb7b739c543b0d5babc4da4797caf3 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -998,7 +998,10 @@ static netdev_features_t bond_fix_features(struct net_device *dev,
NETIF_F_HIGHDMA | NETIF_F_LRO)
#define BOND_ENC_FEATURES (NETIF_F_ALL_CSUM | NETIF_F_SG | NETIF_F_RXCSUM |\
- NETIF_F_TSO | NETIF_F_GSO_UDP_TUNNEL)
+ NETIF_F_TSO)
+
+#define BOND_ENC_ALWAYS (NETIF_F_GSO_GRE | NETIF_F_GSO_IPIP | \
+ NETIF_F_GSO_SIT | NETIF_F_GSO_UDP_TUNNEL)
static void bond_compute_features(struct bonding *bond)
{
@@ -1034,7 +1037,7 @@ static void bond_compute_features(struct bonding *bond)
done:
bond_dev->vlan_features = vlan_features;
- bond_dev->hw_enc_features = enc_features;
+ bond_dev->hw_enc_features = enc_features | BOND_ENC_ALWAYS;
bond_dev->hard_header_len = max_hard_header_len;
bond_dev->gso_max_segs = gso_max_segs;
netif_set_gso_max_size(bond_dev, gso_max_size);
@@ -4010,7 +4013,7 @@ void bond_setup(struct net_device *bond_dev)
NETIF_F_HW_VLAN_CTAG_FILTER;
bond_dev->hw_features &= ~(NETIF_F_ALL_CSUM & ~NETIF_F_HW_CSUM);
- bond_dev->hw_features |= NETIF_F_GSO_UDP_TUNNEL;
+ bond_dev->hw_features |= BOND_ENC_ALWAYS;
bond_dev->features |= bond_dev->hw_features;
}
^ permalink raw reply related
* [PATCH bluetooth-next] ieee802154: cc2520: Replace shift operations by BIT macro
From: Mohammad Jamal @ 2015-01-23 13:58 UTC (permalink / raw)
To: varkabhadram, alex.aring, linux-wpan, netdev, linux-kernel; +Cc: Mohammad Jamal
This patch replaces the shifting operations by BIT macro
Signed-off-by: Mohammad Jamal <md.jamalmohiuddin@gmail.com>
---
drivers/net/ieee802154/cc2520.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ieee802154/cc2520.c b/drivers/net/ieee802154/cc2520.c
index 665a3db..181b349 100644
--- a/drivers/net/ieee802154/cc2520.c
+++ b/drivers/net/ieee802154/cc2520.c
@@ -44,9 +44,9 @@
#define CC2520_FREG_MASK 0x3F
/* status byte values */
-#define CC2520_STATUS_XOSC32M_STABLE (1 << 7)
-#define CC2520_STATUS_RSSI_VALID (1 << 6)
-#define CC2520_STATUS_TX_UNDERFLOW (1 << 3)
+#define CC2520_STATUS_XOSC32M_STABLE BIT(7)
+#define CC2520_STATUS_RSSI_VALID BIT(6)
+#define CC2520_STATUS_TX_UNDERFLOW BIT(3)
/* IEEE-802.15.4 defined constants (2.4 GHz logical channels) */
#define CC2520_MINCHANNEL 11
--
1.7.9.5
^ permalink raw reply related
* Re: [net-next PATCH v3 00/12] Flow API
From: Thomas Graf @ 2015-01-23 14:07 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: <20150123134315.GF2065@nanopsycho.orion>
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.
^ permalink raw reply
* Re: [PATCH] samples/bpf: Fix test_maps/bpf_get_next_key() test
From: Michael Holzheu @ 2015-01-23 14:13 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexei Starovoitov, Martin Schwidefsky,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <CAADnVQ+3exrhp8bS50HEnMrYdg4i3+K7c6ewNZHRkBqtW-uwOA@mail.gmail.com>
On Thu, 22 Jan 2015 09:32:43 -0800
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> On Thu, Jan 22, 2015 at 8:01 AM, Michael Holzheu
> <holzheu@linux.vnet.ibm.com> wrote:
> > Looks like the "test_maps" test case expects to get the keys in
> > the wrong order when iterating over the elements:
> >
> > test_maps: samples/bpf/test_maps.c:79: test_hashmap_sanity: Assertion
> > `bpf_get_next_key(map_fd, &key, &next_key) == 0 && next_key == 2' failed.
> > Aborted
> >
> > Fix this and test for the correct order.
>
> that will break this test on x86...
> we need to understand first why the order of two elements
> came out different on s390...
> Could it be that jhash() produced different hash for the same
> values on x86 vs s390 ?
Yes I think jhash() produces different results for input > 12 bytes
on big and little endian machines because of the following code
in include/linux/jhash.h:
while (length > 12) {
a += __get_unaligned_cpu32(k);
b += __get_unaligned_cpu32(k + 4);
c += __get_unaligned_cpu32(k + 8);
__jhash_mix(a, b, c);
length -= 12;
k += 12;
}
The contents of "k" is directly used as u32 and the result
of "__get_unaligned_cpu32(k)" is different for big and
little endian.
Michael
^ permalink raw reply
* Regression introduced by commit dbe9a4173ea53
From: Jonas Danielsson @ 2015-01-23 14:16 UTC (permalink / raw)
To: davem
Cc: linux-kernel, netdev, ebiederm, luto, rgb, johannes.berg, viro,
akpm, fabf, brian.cambell, mpatocka, tgraf, eric.dumazet, desrt
Hi,
I have seen a regression, that I think is caused by:
commit dbe9a4173ea53b72b2c35d19f676a85b69f1c9fe
Author: Eric W. Biederman <ebiederm@xmission.com>
Date: Thu Sep 6 18:20:01 2012 +0000
scm: Don't use struct ucred in NETLINK_CB and struct scm_cookie.
With this commit the value send as uid when credentials are missing
changes from -1 to overflowuid (default -2, the 'nobody' user).
I was using dbus-send to perform a method call on a gdbus server.
And sometimes I fall victim to the race condition caused by:
commit 16e5726 ("af_unix: dont send SCM_CREDENTIALS by default")
And then there will be no credentials on the socket. The glib library checks
the uid, and if it is -1, it will fall back to using SO_PEERCRED and things
will work for me. But since the commit in $subject changes the uid I get
failure with NoReply from dbus-send.
It seems that before the commit in $subject that the function from_kuid_munged
was only called if there were credentials present. Otherwise we would set uid
to -1. Now uid gets set to -1 if there is no credentials but from_kuid_munged
is always called. And from the documentation of from_kuid_munged it states
that it 'never fails and always returns a valid uid'. And in the case of
uid being -1, it returns overflowuid.
So this seems like it broke glib. Caused by 1) the introduced race condition
that makes it not totally safe to set SO_PEERCRED on the accepted socket and
2) that the value of uid when credentials are missing changed from -1 to
overflowuid.
Thanks for your time
Jonas
^ permalink raw reply
* Re: [patch net-next RFC] tc: introduce OpenFlow classifier
From: Thomas Graf @ 2015-01-23 15:11 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, jhs
In-Reply-To: <1421933824-17916-1-git-send-email-jiri@resnulli.us>
On 01/22/15 at 02:37pm, Jiri Pirko wrote:
> This patch introduces OpenFlow-based filter. So far, the very essential
> packet fields are supported (according to OpenFlow v1.4 spec).
>
> Known issues: skb_flow_dissect hashes out ipv6 addresses. That needs
> to be changed to store them somewhere so they can be used later on.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Since OpenFlow is a wire protocol the description could be somewhat
confusing as you are not actually implementing OpenFlow. Maybe call
this "OpenFlow inspired classifier" or something along those lines?
> diff --git a/net/sched/Kconfig b/net/sched/Kconfig
> index 475e35e..9b01fae 100644
> --- a/net/sched/Kconfig
> +++ b/net/sched/Kconfig
> @@ -477,6 +477,17 @@ config NET_CLS_BPF
> To compile this code as a module, choose M here: the module will
> be called cls_bpf.
>
> +config NET_CLS_OPENFLOW
> + tristate "OpenFlow classifier"
> + select NET_CLS
> + ---help---
> + If you say Y here, you will be able to classify packets based on
> + a configurable combination of packet keys and masks accordint to
^^^
Typo
> +struct of_flow_key {
> + int indev_ifindex;
> + struct {
> + u8 src[ETH_ALEN];
> + u8 dst[ETH_ALEN];
> + __be16 type;
> + } eth;
> + struct {
> + u8 proto;
> + } ip;
> + union {
> + struct {
> + __be32 src;
> + __be32 dst;
> + } ipv4;
> + struct {
> + struct in6_addr src;
> + struct in6_addr dst;
> + } ipv6;
> + };
> + union {
> + struct {
> + __be16 src;
> + __be16 dst;
> + } tp;
> + };
> +} __aligned(BITS_PER_LONG / 8); /* Ensure that we can do comparisons as longs. */
I'm sure you considered this already. Any advantage in sharing the
flow key definition w/ OVS?
> +static void of_extract_key(struct sk_buff *skb, struct of_flow_key *skb_key)
> +{
> + struct flow_keys flow_keys;
> + struct ethhdr *eth;
> +
> + skb_key->indev_ifindex = skb->skb_iif;
> +
> + eth = eth_hdr(skb);
> + ether_addr_copy(skb_key->eth.src, eth->h_source);
> + ether_addr_copy(skb_key->eth.dst, eth->h_dest);
> +
> + skb_flow_dissect(skb, &flow_keys);
> + skb_key->eth.type = flow_keys.n_proto;
> + skb_key->ip.proto = flow_keys.ip_proto;
> + skb_key->ipv4.src = flow_keys.src;
> + skb_key->ipv4.dst = flow_keys.dst;
> + skb_key->tp.src = flow_keys.port16[0];
> + skb_key->tp.dst = flow_keys.port16[1];
> +}
If I understand skb_flow_dissect() correctly then you will always
fill of_flow_key with the inner most header. How would you for
example match on the outer UDP header?
> +static bool of_match(struct of_flow_key *skb_key, struct cls_of_filter *f)
> +{
> + const long *lkey = (const long *) &f->match.key;
> + const long *lmask = (const long *) &f->match.mask;
> + const long *lskb_key = (const long *) skb_key;
> + int i;
> +
> + for (i = 0; i < sizeof(struct of_flow_key); i += sizeof(const long)) {
> + if ((*lkey++ & *lmask) != (*lskb_key++ & *lmask))
> + return false;
> + lmask++;
> + }
> + return true;
> +}
Nice. An further possible optimization would be to calculate the
length of the flow key that must match and cut off the flow key if
the remaining bits are all wildcarded, e.g. eth header only match.
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: Jiri Pirko @ 2015-01-23 15:25 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: <20150123140724.GJ25797@casper.infradead.org>
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.
>
>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.
flow manipulation would happen as standard TC filters/actions manipulation.
Here, the Netlink messages could be also very similar to what John has now.
>
>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.
^ permalink raw reply
* Re: [PATCH V2 for 3.19 0/7] Fixes for rtl8192ee
From: Kalle Valo @ 2015-01-23 15:26 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, netdev
In-Reply-To: <1421773286-1039-1-git-send-email-Larry.Finger@lwfinger.net>
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 Valo
^ permalink raw reply
* Re: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
From: Kalle Valo @ 2015-01-23 15:29 UTC (permalink / raw)
To: Arend van Spriel
Cc: Sergei Shtylyov, Fu, Zhonghui, brudley-dY08KVG/lbpWk0Htik3J/w,
Franky Lin, meuleman-dY08KVG/lbpWk0Htik3J/w,
linville-2XuSBdqkA4R54TAoqtyWWQ, pieterpg-dY08KVG/lbpWk0Htik3J/w,
hdegoede-H+wXaHxf7aLQT0dZR+AlfA, wens-jdAy2FN1RRM,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-kernel@vger.kernel.org
In-Reply-To: <54C1646B.4080409-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Arend van Spriel <arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> writes:
> On 01/22/15 14:54, Sergei Shtylyov wrote:
>> Hello.
>>
>> On 1/22/2015 4:49 PM, Kalle Valo wrote:
>>
>>>> >From 04d3fa673897ca4ccbea6c76836d0092dba2484a Mon Sep 17 00:00:00 2001
>>>> From: Zhonghui Fu <zhonghui.fu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>>>> Date: Tue, 20 Jan 2015 11:14:13 +0800
>>>> Subject: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
>>
>>>> WiFi chip has 2 SDIO functions, and PM core will trigger
>>>> twice suspend/resume operations for one WiFi chip to do
>>>> the same things. This patch avoid this case.
>>
>>>> Acked-by: Arend van Spriel <arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>>>> Acked-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
>>>> Acked-by: Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>>> Signed-off-by: Zhonghui Fu <zhonghui.fu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>>
>>> I don't remember giving Acked-by to this (or for matter to anything for
>>> a long time). What about Sergei or Arend?
>>
>> I haven't ACK'ed this patch either.
>
> I did ACK the initial patch and felt it still valid for this 'V2' patch.
Ok, thanks. So the patch is good, Zhonghui just needs to remove the two
acked-by lines.
--
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
* pull-request: mac80211 2015-01-23
From: Johannes Berg @ 2015-01-23 15:33 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev
Hi Dave,
I have a few more fixes that seemed relevant for the current cycle and
low enough impact to merge at this point.
However, I can live with all of this going to -next as well since most
are difficult to hit in practice.
johannes
The following changes since commit 20658702e08ecd693236b443837d28863b93e872:
cfg80211: fix deadlock during reg chan check (2015-01-07 14:53:46 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2015-01-23
for you to fetch changes up to 0fa7b39131576dd1baa6ca17fca53c65d7f62249:
nl80211: fix per-station group key get/del and memory leak (2015-01-23 11:21:02 +0100)
----------------------------------------------------------------
Another set of last-minute fixes:
* fix station double-removal when suspending while associating
* fix the HT (802.11n) header length calculation
* fix the CCK radiotap flag used for monitoring, a pretty
old regression but a simple one-liner
* fix per-station group-key handling
----------------------------------------------------------------
Fred Chou (1):
mac80211: correct header length calculation
Johannes Berg (1):
nl80211: fix per-station group key get/del and memory leak
Luciano Coelho (1):
mac80211: only roll back station states for WDS when suspending
Mathy Vanhoef (1):
mac80211: properly set CCK flag in radiotap
net/mac80211/pm.c | 29 +++++++++++++++--------------
net/mac80211/rx.c | 2 +-
net/wireless/nl80211.c | 9 ++++-----
net/wireless/util.c | 6 ++++++
4 files changed, 26 insertions(+), 20 deletions(-)
--
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
* Re: [net-next PATCH v3 00/12] Flow API
From: John Fastabend @ 2015-01-23 15:34 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: <20150123140724.GJ25797@casper.infradead.org>
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.
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.
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: [patch net-next RFC] tc: introduce OpenFlow classifier
From: Jiri Pirko @ 2015-01-23 15:38 UTC (permalink / raw)
To: Thomas Graf; +Cc: netdev, davem, jhs
In-Reply-To: <20150123151145.GK25797@casper.infradead.org>
Fri, Jan 23, 2015 at 04:11:45PM CET, tgraf@suug.ch wrote:
>On 01/22/15 at 02:37pm, Jiri Pirko wrote:
>> This patch introduces OpenFlow-based filter. So far, the very essential
>> packet fields are supported (according to OpenFlow v1.4 spec).
>>
>> Known issues: skb_flow_dissect hashes out ipv6 addresses. That needs
>> to be changed to store them somewhere so they can be used later on.
>>
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>
>Since OpenFlow is a wire protocol the description could be somewhat
>confusing as you are not actually implementing OpenFlow. Maybe call
>this "OpenFlow inspired classifier" or something along those lines?
Yep, therefore I do not call it "OpenFlow" but rather
"Openflow-classifier". But sure, I will rename it to make it clearer
>
>> diff --git a/net/sched/Kconfig b/net/sched/Kconfig
>> index 475e35e..9b01fae 100644
>> --- a/net/sched/Kconfig
>> +++ b/net/sched/Kconfig
>> @@ -477,6 +477,17 @@ config NET_CLS_BPF
>> To compile this code as a module, choose M here: the module will
>> be called cls_bpf.
>>
>> +config NET_CLS_OPENFLOW
>> + tristate "OpenFlow classifier"
>> + select NET_CLS
>> + ---help---
>> + If you say Y here, you will be able to classify packets based on
>> + a configurable combination of packet keys and masks accordint to
> ^^^
>
>Typo
Yep, already fixed.
>
>> +struct of_flow_key {
>> + int indev_ifindex;
>> + struct {
>> + u8 src[ETH_ALEN];
>> + u8 dst[ETH_ALEN];
>> + __be16 type;
>> + } eth;
>> + struct {
>> + u8 proto;
>> + } ip;
>> + union {
>> + struct {
>> + __be32 src;
>> + __be32 dst;
>> + } ipv4;
>> + struct {
>> + struct in6_addr src;
>> + struct in6_addr dst;
>> + } ipv6;
>> + };
>> + union {
>> + struct {
>> + __be16 src;
>> + __be16 dst;
>> + } tp;
>> + };
>> +} __aligned(BITS_PER_LONG / 8); /* Ensure that we can do comparisons as longs. */
>
>I'm sure you considered this already. Any advantage in sharing the
>flow key definition w/ OVS?
For now, I support much less than ovs here. Therefore I wanted to keep
the key simple. But I count with the eventual code merge with ovs in
this matter.
>
>> +static void of_extract_key(struct sk_buff *skb, struct of_flow_key *skb_key)
>> +{
>> + struct flow_keys flow_keys;
>> + struct ethhdr *eth;
>> +
>> + skb_key->indev_ifindex = skb->skb_iif;
>> +
>> + eth = eth_hdr(skb);
>> + ether_addr_copy(skb_key->eth.src, eth->h_source);
>> + ether_addr_copy(skb_key->eth.dst, eth->h_dest);
>> +
>> + skb_flow_dissect(skb, &flow_keys);
>> + skb_key->eth.type = flow_keys.n_proto;
>> + skb_key->ip.proto = flow_keys.ip_proto;
>> + skb_key->ipv4.src = flow_keys.src;
>> + skb_key->ipv4.dst = flow_keys.dst;
>> + skb_key->tp.src = flow_keys.port16[0];
>> + skb_key->tp.dst = flow_keys.port16[1];
>> +}
>
>If I understand skb_flow_dissect() correctly then you will always
>fill of_flow_key with the inner most header. How would you for
>example match on the outer UDP header?
Yes, flow dissect is not ideal for this usage, for example also for the
ipv6 addresses hashing. I was thinking about extending it. Eventually,
this code can be merged with ovs as well.
>
>> +static bool of_match(struct of_flow_key *skb_key, struct cls_of_filter *f)
>> +{
>> + const long *lkey = (const long *) &f->match.key;
>> + const long *lmask = (const long *) &f->match.mask;
>> + const long *lskb_key = (const long *) skb_key;
>> + int i;
>> +
>> + for (i = 0; i < sizeof(struct of_flow_key); i += sizeof(const long)) {
>> + if ((*lkey++ & *lmask) != (*lskb_key++ & *lmask))
>> + return false;
>> + lmask++;
>> + }
>> + return true;
>> +}
>
>Nice. An further possible optimization would be to calculate the
>length of the flow key that must match and cut off the flow key if
>the remaining bits are all wildcarded, e.g. eth header only match.
Yep, I have another optimization ideas. I just focused to getting this
to work first, optimize later on.
^ 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
* 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: [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 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: 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: [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: 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_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: [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: [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: [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: [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: 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
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