* Re: [net-next PATCH v3 00/12] Flow API
From: Jiri Pirko @ 2015-01-23 11:39 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: <20150123110821.GH25797@casper.infradead.org>
Fri, Jan 23, 2015 at 12:08:21PM CET, tgraf@suug.ch wrote:
>On 01/23/15 at 11:24am, Jiri Pirko wrote:
>> I think that comparing this to team or routing userspace is not
>> correct. The reason is that team and routing has single api to kernel.
>> However in this case userspace has to use multiple APIs.
>
>The point I was trying to make is that there are legitimate reasons
>to keep complexity out of the kernel and team is a good example for
>that.
>
>As for multiple APIs. Team does in fact export its own Generic Netlink
>interface while it also hooks into rtnetlink to support ip link. Not
>sure whether that qualifies for multiple APIs or not but I think it's
>an excellent architecture decision. Same as for nl80211 tools.
Team uses multiple api for sure, but for different things.
>
>> For example OVS. It would have to use existing OVS gennetlink iface + this
>> new flow netlink iface for flow offloads. For all others, this is the same.
>> Multiple apis for the same thing (does not matter if it is implemented
>> in hw or sw) does not seem right to me.
>
>Fair enough. I have no objections to merging the flow API into RTNETLINK
>although I don't really see a need to put more under the rtnl umbrella
>unless absolutely required.
>
>I think John also mentioned that he proposes to have this as a separate
>Generic Netlink interface for now but this could really live wherever it
>seems appropriate.
Maybe I did not express myself correctly. I do not care if this is
exposed by rtnl or a separate genetlink. The issue still stands. And the
issue is that the user have to use "the way A" to setup sw datapath and
"the way B" to setup hw datapath. The preferable would be to have
"the way X" which can be used to setup both sw and hw.
And I believe that could be achieved. Consider something like this:
- have cls_xflows tc classifier and act_xflows tc action as a wrapper
(or api) for John's work. With possibility for multiple backends. The
backend iface would looke very similar to what John has now.
- other tc clses and acts will implement xflows backend
- openvswitch datapath will implement xflows backend
- rocker switch will implement xflows backend
- other drivers will implement xflows backend
Now if user wants to manipulate with any flow setting, he can just use
cls_xflows and act_xflows to to that.
This is very rough, but I just wanted to draw the picture. This would
provide single entry to flow world manipulation in kernel, no matter if
sw or hw.
Thoughts?
^ permalink raw reply
* Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached
From: Daniel Borkmann @ 2015-01-23 11:50 UTC (permalink / raw)
To: Sun Paul; +Cc: linux-sctp, netdev, linux-kernel, vyasevich
In-Reply-To: <CAFXGft+fwo=8LJEG7h6uOpGciSo5f_dXjSx3sn67RZZp7jsYHw@mail.gmail.com>
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.
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,
^ permalink raw reply related
* Bug#776040: [PATCH] iproute2/ip: fix up filter when printing addresses
From: Andreas Henriksson @ 2015-01-23 12:10 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Andreas Henriksson, 776040
"ip addr show up" would exclude the interface (link), but include the
addresses of down interfaces (which looked like they where indented
under a different interface). This fixes the filtering.
For a full example see the original bug report at:
http://bugs.debian.org/776040
Reported-by: Paul Slootman <paul@debian.org>
CC: 776040@bugs.debian.org
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
---
ip/ipaddress.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index d5e863d..3730424 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -970,7 +970,8 @@ struct nlmsg_chain
struct nlmsg_list *tail;
};
-static int print_selected_addrinfo(int ifindex, struct nlmsg_list *ainfo, FILE *fp)
+static int print_selected_addrinfo(struct ifinfomsg *ifi,
+ struct nlmsg_list *ainfo, FILE *fp)
{
for ( ;ainfo ; ainfo = ainfo->next) {
struct nlmsghdr *n = &ainfo->h;
@@ -982,10 +983,13 @@ static int print_selected_addrinfo(int ifindex, struct nlmsg_list *ainfo, FILE *
if (n->nlmsg_len < NLMSG_LENGTH(sizeof(ifa)))
return -1;
- if (ifa->ifa_index != ifindex ||
+ if (ifa->ifa_index != ifi->ifi_index ||
(filter.family && filter.family != ifa->ifa_family))
continue;
+ if (filter.up && !(ifi->ifi_flags&IFF_UP))
+ continue;
+
print_addrinfo(NULL, n, fp);
}
return 0;
@@ -1446,7 +1450,7 @@ static int ipaddr_list_flush_or_save(int argc, char **argv, int action)
if (no_link || (res = print_linkinfo(NULL, &l->h, stdout)) >= 0) {
struct ifinfomsg *ifi = NLMSG_DATA(&l->h);
if (filter.family != AF_PACKET)
- print_selected_addrinfo(ifi->ifi_index,
+ print_selected_addrinfo(ifi,
ainfo.head, stdout);
if (res > 0 && !do_link && show_stats)
print_link_stats(stdout, &l->h);
--
2.1.4
^ permalink raw reply related
* Re: net: prevent of emerging cross-namespace symlinks patches for 3.14?
From: Luis Henriques @ 2015-01-23 12:14 UTC (permalink / raw)
To: Miquel van Smoorenburg
Cc: netdev, stable, Alexander Y. Fomichev, David Miller
In-Reply-To: <54B6E36F.9060703@xs4all.net>
On Wed, Jan 14, 2015 at 10:45:19PM +0100, Miquel van Smoorenburg wrote:
> [first sent to lkml, now to netdev and the original patch author]
>
> When running 'lxc' on the latest -stable kernel, 3.14.28, I'm seeing these
> errors:
>
> Jan 14 17:47:16 lxc2 kernel: [ 10.704890] WARNING: CPU: 0 PID: 3209 at
> fs/sys
> fs/dir.c:52 sysfs_warn_dup+0x8c/0xb0()
> Jan 14 17:47:16 lxc2 kernel: [ 10.704892] sysfs: cannot create duplicate
> filename '/devices/virtual/net/eth0.104/upper_eth0'
> Jan 14 17:47:16 lxc2 kernel: [ 10.704954] CPU: 0 PID: 3209 Comm:
> lxc-autostart Not tainted 3.14.28-xsserver #1
>
> I did not see these errors in 3.12. This was fixed in 3.17 by:
>
> net: prevent of emerging cross-namespace symlinks
> https://github.com/torvalds/linux/commit/4c75431ac3520631f1d9e74aa88407e6374dbbc4
>
> net: fix creation adjacent device symlinks
> https://github.com/torvalds/linux/commit/7ce64c79c4decdeb1afe0bf2f6ef834b382871d1
>
> These patches apply cleanly to 3.14.28.
>
> If you agree that this should go into 3.14-stable, please ack.
>
Thank you, I am queuing these 2 patches for the 3.16 kernel as well.
Cheers,
--
Luís
> Thanks,
>
> Mike.
> --
> To unsubscribe from this list: send the line "unsubscribe stable" 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: [RFC PATCH] net: ipv6: Make address flushing on ifdown optional
From: Hannes Frederic Sowa @ 2015-01-23 12:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Ahern, netdev
In-Reply-To: <20150122224033.6e2db5ce@urahara>
On Do, 2015-01-22 at 22:40 -0800, Stephen Hemminger wrote:
> On Wed, 14 Jan 2015 12:17:19 -0700
> David Ahern <dsahern@gmail.com> 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
> >
> > Suggested-by: Hannes Frederic Sowa <hannes@redhat.com>
> > Signed-off-by: David Ahern <dsahern@gmail.com>
> > Cc: Hannes Frederic Sowa <hannes@redhat.com>
>
> Would this break existing application expecting a particular semantic
> by listening to netlink? What happens to packets received with the static
> address when interface is down? With IPv4 Linux is mostly a weak host
> model, and IPv6 somewhere in between.
IPv6 is mostly a weak end model, too, but IFA_LINK addresses are used
much more. So yes, it is somewhere in between.
Addresses bound to interfaces which are currently down will work with
IPv6 (in contrast to IPv4).
> For vendors that control the application stack or have limited number
> of services this would work fine, but what about RHEL?
The new model is only enabled if the sysctl is set. I don't expect a lot
of vendors or distributions switching anytime soon.
I wonder if we should try to come up with a way of IPV6_NEW_WORLD_ORDER
we can make some changes to the stack which align much better with the
RFCs, e.g. no default link local address generation, no default on-link
routes etc.
Bye,
Hannes
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: Thomas Graf @ 2015-01-23 12:28 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: <20150123113934.GD2065@nanopsycho.orion>
On 01/23/15 at 12:39pm, Jiri Pirko wrote:
> Maybe I did not express myself correctly. I do not care if this is
> exposed by rtnl or a separate genetlink. The issue still stands. And the
> issue is that the user have to use "the way A" to setup sw datapath and
> "the way B" to setup hw datapath. The preferable would be to have
> "the way X" which can be used to setup both sw and hw.
>
> And I believe that could be achieved. Consider something like this:
>
> - have cls_xflows tc classifier and act_xflows tc action as a wrapper
> (or api) for John's work. With possibility for multiple backends. The
> backend iface would looke very similar to what John has now.
> - other tc clses and acts will implement xflows backend
> - openvswitch datapath will implement xflows backend
> - rocker switch will implement xflows backend
> - other drivers will implement xflows backend
>
> Now if user wants to manipulate with any flow setting, he can just use
> cls_xflows and act_xflows to to that.
>
> This is very rough, but I just wanted to draw the picture. This would
> provide single entry to flow world manipulation in kernel, no matter if
> sw or hw.
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.
If you look at this from the existing tc world then that makes a lot
of sense, in particular if you only support a single flat table with
wildcard flows and no priorities.
If you want to support priorities it already gets complicated. If flow
A, B, C are offloaded to hardware and the user then inserts a new flow
D with higher priority that can't be offloaded you need to figure out
whether you have to remove any of A, B, C from the hardware tables again
on the basis whether D overlaps with A, B, or C. If you have to remove
any of them you then have to verify whether that removal needs to
remove other already offloaded flows as well. It's certainly doable but
already adds considerable complexity to the kernel.
If you want to support multiple tables it gets even more complicated
because a flow in table 2 which can be offloaded might depend on a
flow in table 1 which can't be offloaded. You somehow need to track
that dependency and ensure that table 1 sends that flow to the CPU so
that the flow in table 2 sees it. The answer to this might be to maybe
only support offload to a single table but that decreases the value
of the offload dramatically because the capabilities of each table are
very different.
If you bring the full programmability of OVS into the picture you might
have a pipeline consisting of multiple tables like this:
+-------+ +------+ +-----+ +-------+
| Decap |-->| L2 |-->| L3 |-->| Encap |
+-------+ +------+ +-----+ +-------+
Each table contains flows and metadata registers plus header matches
are used to talk among the tables. The pipeline builds a chain of
actions which may be executed at any point in the pipeline or at the
end. If you want to map such a software pipeline to a set of hardware
tables you need to have full visbility into this table structure at
the point where you make the offload decision. This means that all of
this complexity would have to move into xflows.
Another aspect is that you might want to split a flow X into a hardware
and software part, e.g. consider the following flow:
in_port=vxlan0,vni=10,ip_dst=10.1.1.1,actions=decap(),nfqueue(10),output(tap0)
The hardware might be capable of matching on the VXLAN VNI, IP dst and
it might also capable of deencap. It obviously doesn't know about
netfilter queues. Ideally what you want is to split this into the
following flows:
Hardware table (offloaded):
in_port=vxlan0,vni=10,ip_dst=10.1.1.1,actions=decap(),metadata=1
Software table:
metadata=1,actions=nfqueue(10),output(tap0)
If the hardware capabilities are not exported to OVS then xflows would
need to encode such logic and xflows would need to be made aware of the
full software pipeline with all tables as you need to see all flows in
order to decide what to offload where.
I would love to see a tc interface to John's flow API and I see
tremendous value but I don't think it's appropriate to offload OVS.
^ permalink raw reply
* Re: [PATCH] net: ieee802154: cc2520: Fix coding style issues
From: Sergei Shtylyov @ 2015-01-23 12:37 UTC (permalink / raw)
To: Mohammad Jamal, varkabhadram, alex.aring, linux-wpan, netdev,
linux-kernel
In-Reply-To: <1422005180-13230-1-git-send-email-md.jamalmohiuddin@gmail.com>
Hello.
On 1/23/2015 12:26 PM, Mohammad Jamal wrote:
> This patch solves the coding style issues such as space after ,
s/after/before/?
> and removes the blank lines
Extra blank lines, you mean?
> Signed-off-by: Mohammad Jamal <md.jamalmohiuddin@gmail.com>
> ---
> drivers/net/ieee802154/cc2520.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
> diff --git a/drivers/net/ieee802154/cc2520.c b/drivers/net/ieee802154/cc2520.c
> index f9df9fa..dd129be 100644
> --- a/drivers/net/ieee802154/cc2520.c
> +++ b/drivers/net/ieee802154/cc2520.c
[...]
> @@ -551,14 +550,14 @@ cc2520_ed(struct ieee802154_hw *hw, u8 *level)
> u8 rssi;
> int ret;
>
> - ret = cc2520_read_register(priv , CC2520_RSSISTAT, &status);
> + ret = cc2520_read_register(priv, CC2520_RSSISTAT, &status);
> if (ret)
> return ret;
>
> if (status != RSSI_VALID)
> return -EINVAL;
>
> - ret = cc2520_read_register(priv , CC2520_RSSI, &rssi);
> + ret = cc2520_read_register(priv, CC2520_RSSI, &rssi);
[...]
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] net: ieee802154: cc2520: Fix coding style issues
From: Jamal Mohammad @ 2015-01-23 12:44 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Varka Bhadram, Alexander Aring, linux-wpan - ML,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <54C2409A.6020506@cogentembedded.com>
On Fri, Jan 23, 2015 at 6:07 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Hello.
>
> On 1/23/2015 12:26 PM, Mohammad Jamal wrote:
>
>> This patch solves the coding style issues such as space after ,
>
>
> s/after/before/?
>
>> and removes the blank lines
>
>
> Extra blank lines, you mean?
>
>> Signed-off-by: Mohammad Jamal <md.jamalmohiuddin@gmail.com>
>> ---
>> drivers/net/ieee802154/cc2520.c | 6 ++----
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>
>
>> diff --git a/drivers/net/ieee802154/cc2520.c
>> b/drivers/net/ieee802154/cc2520.c
>> index f9df9fa..dd129be 100644
>> --- a/drivers/net/ieee802154/cc2520.c
>> +++ b/drivers/net/ieee802154/cc2520.c
>
> [...]
>>
>> @@ -551,14 +550,14 @@ cc2520_ed(struct ieee802154_hw *hw, u8 *level)
>> u8 rssi;
>> int ret;
>>
>> - ret = cc2520_read_register(priv , CC2520_RSSISTAT, &status);
>> + ret = cc2520_read_register(priv, CC2520_RSSISTAT, &status);
>> if (ret)
>> return ret;
>>
>> if (status != RSSI_VALID)
>> return -EINVAL;
>>
>> - ret = cc2520_read_register(priv , CC2520_RSSI, &rssi);
>> + ret = cc2520_read_register(priv, CC2520_RSSI, &rssi);
>
> [...]
>
> WBR, Sergei
>
Sorry for that,
i actually have cloned and linus torvalds git and when i ran
checkpatch.pl i have found some warnings. so this patch was removing
those warnings...as bhadram told that these warnings are already
removed in bluetooth-next tree...so this patch any how fails....
^ permalink raw reply
* RE: [PATCH net-next v3 3/5] bridge: offload bridge port attributes to switch asic if feature flag set
From: Rosen, Rami @ 2015-01-23 12:53 UTC (permalink / raw)
To: roopa@cumulusnetworks.com, 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
Cc: netdev@vger.kernel.org, davem@davemloft.net,
shm@cumulusnetworks.com, gospo@cumulusnetworks.com
In-Reply-To: <1421987606-10884-4-git-send-email-roopa@cumulusnetworks.com>
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.
Regards,
Rami Rosen
Intel Corporation
^ permalink raw reply
* NetDev 0.1 conference: Important! Hotel Reservation Deadline Expiring
From: Jamal Hadi Salim @ 2015-01-23 13:27 UTC (permalink / raw)
To: netdev, linux-wireless, lwn, netdev01, lartc, netfilter,
netfilter-devel
Cc: Richard Guy Briggs, info, speakers, attendees
Fellow netheads:
On behalf of rgb, yours truly is sending out this announcement.
Today is the last day that the Westin Hotel will be holding a block of
rooms for Netdev01 at a guaranteed rate of $159.00 or $179.00
(depending on the type of room required) and there are still rooms
available.
Please dont procastinate and book now. We are trying to negotiate with
the hotel to see if they can extend the deadline but so far we have not
been successful. We are competing against a few tourist activities for
hotel rooms going on around the area at the same time (example:
http://www.ottawafestivals.ca/events/winterlude-2/) so we can assure you
the prices will go up.
The content of the Tutorials/BOFs/talk continues to be updated at:
https://www.netdev01.org/sessions
This has to be the most amazing Linux netdev content put together
anywhere.
Avoid disappointment and do your reservations at:
https://www.starwoodmeeting.com/StarGroupsWeb/res?id=1412035802&key=1AC9C1F8
cheers,
jamal (on behalf of Richard Guy Briggs)
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: Jiri Pirko @ 2015-01-23 13:43 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: <20150123122838.GI25797@casper.infradead.org>
Fri, Jan 23, 2015 at 01:28:38PM CET, tgraf@suug.ch wrote:
>On 01/23/15 at 12:39pm, Jiri Pirko wrote:
>> Maybe I did not express myself correctly. I do not care if this is
>> exposed by rtnl or a separate genetlink. The issue still stands. And the
>> issue is that the user have to use "the way A" to setup sw datapath and
>> "the way B" to setup hw datapath. The preferable would be to have
>> "the way X" which can be used to setup both sw and hw.
>>
>> And I believe that could be achieved. Consider something like this:
>>
>> - have cls_xflows tc classifier and act_xflows tc action as a wrapper
>> (or api) for John's work. With possibility for multiple backends. The
>> backend iface would looke very similar to what John has now.
>> - other tc clses and acts will implement xflows backend
>> - openvswitch datapath will implement xflows backend
>> - rocker switch will implement xflows backend
>> - other drivers will implement xflows backend
>>
>> Now if user wants to manipulate with any flow setting, he can just use
>> cls_xflows and act_xflows to to that.
>>
>> This is very rough, but I just wanted to draw the picture. This would
>> provide single entry to flow world manipulation in kernel, no matter if
>> sw or hw.
>
>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).
>
>If you look at this from the existing tc world then that makes a lot
>of sense, in particular if you only support a single flat table with
>wildcard flows and no priorities.
>
>If you want to support priorities it already gets complicated. If flow
>A, B, C are offloaded to hardware and the user then inserts a new flow
>D with higher priority that can't be offloaded you need to figure out
>whether you have to remove any of A, B, C from the hardware tables again
>on the basis whether D overlaps with A, B, or C. If you have to remove
>any of them you then have to verify whether that removal needs to
>remove other already offloaded flows as well. It's certainly doable but
>already adds considerable complexity to the kernel.
>
>If you want to support multiple tables it gets even more complicated
>because a flow in table 2 which can be offloaded might depend on a
>flow in table 1 which can't be offloaded. You somehow need to track
>that dependency and ensure that table 1 sends that flow to the CPU so
>that the flow in table 2 sees it. The answer to this might be to maybe
>only support offload to a single table but that decreases the value
>of the offload dramatically because the capabilities of each table are
>very different.
>
>If you bring the full programmability of OVS into the picture you might
>have a pipeline consisting of multiple tables like this:
>
> +-------+ +------+ +-----+ +-------+
> | Decap |-->| L2 |-->| L3 |-->| Encap |
> +-------+ +------+ +-----+ +-------+
>
>Each table contains flows and metadata registers plus header matches
>are used to talk among the tables. The pipeline builds a chain of
>actions which may be executed at any point in the pipeline or at the
>end. If you want to map such a software pipeline to a set of hardware
>tables you need to have full visbility into this table structure at
>the point where you make the offload decision. This means that all of
>this complexity would have to move into xflows.
>
>Another aspect is that you might want to split a flow X into a hardware
>and software part, e.g. consider the following flow:
>
>in_port=vxlan0,vni=10,ip_dst=10.1.1.1,actions=decap(),nfqueue(10),output(tap0)
>
>The hardware might be capable of matching on the VXLAN VNI, IP dst and
>it might also capable of deencap. It obviously doesn't know about
>netfilter queues. Ideally what you want is to split this into the
>following flows:
>
>Hardware table (offloaded):
>in_port=vxlan0,vni=10,ip_dst=10.1.1.1,actions=decap(),metadata=1
>
>Software table:
>metadata=1,actions=nfqueue(10),output(tap0)
>
>If the hardware capabilities are not exported to OVS then xflows would
>need to encode such logic and xflows would need to be made aware of the
>full software pipeline with all tables as you need to see all flows in
>order to decide what to offload where.
>
>I would love to see a tc interface to John's flow API and I see
>tremendous value but I don't think it's appropriate to offload OVS.
^ permalink raw reply
* [PATCH bluetooth-next] ieee802154: cc2520: Fix space before , coding style issue
From: Mohammad Jamal @ 2015-01-23 13:55 UTC (permalink / raw)
To: varkabhadram, alex.aring, linux-wpan, netdev, linux-kernel; +Cc: Mohammad Jamal
This patch removes the warnings (space before , ) shown by
checkpatch.pl
Signed-off-by: Mohammad Jamal <md.jamalmohiuddin@gmail.com>
---
drivers/net/ieee802154/cc2520.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/cc2520.c b/drivers/net/ieee802154/cc2520.c
index a43c8ac..665a3db 100644
--- a/drivers/net/ieee802154/cc2520.c
+++ b/drivers/net/ieee802154/cc2520.c
@@ -549,14 +549,14 @@ cc2520_ed(struct ieee802154_hw *hw, u8 *level)
u8 rssi;
int ret;
- ret = cc2520_read_register(priv , CC2520_RSSISTAT, &status);
+ ret = cc2520_read_register(priv, CC2520_RSSISTAT, &status);
if (ret)
return ret;
if (status != RSSI_VALID)
return -EINVAL;
- ret = cc2520_read_register(priv , CC2520_RSSI, &rssi);
+ ret = cc2520_read_register(priv, CC2520_RSSI, &rssi);
if (ret)
return ret;
--
1.7.9.5
^ permalink raw reply related
* [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
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