* Re: linux-next: manual merge of the rdma tree with the net-next tree
From: Doug Ledford @ 2016-03-16 17:35 UTC (permalink / raw)
To: Linus Torvalds, Stephen Rothwell
Cc: David Miller, Network Development, linux-next,
Linux Kernel Mailing List, Amir Vadai, Maor Gottlieb
In-Reply-To: <CA+55aFzhYJxCOXER-mhOfJ6=V13Rb5F0LB_3A9n7S_dLkb8f0g@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 953 bytes --]
On 3/16/2016 1:18 PM, Linus Torvalds wrote:
> On Tue, Mar 15, 2016 at 5:58 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> I fixed it up (see below) and can carry the fix as necessary (no action
>> is required).
>
> Side note: can you change this wording for your manual merge script?
> Last merge window (or was it the one before it?) we had confusion with
> people who thought that "no action is required" means "you can just
> ignore this entirely".
I certainly didn't take it that way regardless of the wording. I'm
keenly aware of the short leash you have Mellanox (and by extension
myself) on. I reviewed the merge in detail, enough to satisfy myself
that it was easy, correct, and that the code itself made the merge
obvious (such as the comment that flow table entries need to be last in
the lists in order to support priority transitions, which fairly handily
explained what needed to happen in the merge).
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] vxlan: implement GPE
From: Jiri Benc @ 2016-03-16 17:38 UTC (permalink / raw)
To: Tom Herbert; +Cc: Linux Kernel Network Developers, Jesse Gross
In-Reply-To: <CALx6S37n=4-VUTOx7cZuAaVOFa4=wtGgd7iBwAk8pMNmpt_vcA@mail.gmail.com>
On Wed, 16 Mar 2016 10:31:10 -0700, Tom Herbert wrote:
> Sorry, I still don't like this. For VXLAN-GPE packets the above two
> conditionals are a complete waste of time and I shouldn't have to go
> pawing through configuration to determine what protocol has actually
> be implemented. Please, at least move these into the else block of
> "if (vs->flags & VXLAN_F_GPE) {" above. This saves two conditionals in
> the data path, makes the parsing code more readable, and you don't
> need to reference configuration to figure things out.
As I already wrote, this is not possible. GPE parsing needs to occur
before iptunnel_pull_header (because we need to know the protocol), GBP
parsing needs to happen after it (after udp_tun_rx_dst specifically).
Believe me, I would do it that way if it was possible.
I also considered splitting rx path for GPE and non-GPE case and the
result was much uglier and longer code.
Jiri
^ permalink raw reply
* Re: 4.5.0 on sun7i-a20-olinuxino-lime2: libphy: PHY stmmac-0:ffffffff not found (regression from rc7)
From: Marc Zyngier @ 2016-03-16 17:42 UTC (permalink / raw)
To: Bert Lindner, Andreas Färber, Robin Murphy
Cc: Maxime Ripard, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA, Giuseppe Cavallaro
In-Reply-To: <56E9776F.3070102-phGP8mJ4Mqk@public.gmane.org>
On 16/03/16 15:10, Bert Lindner wrote:
> On 2016-03-16 14:10, Andreas Färber wrote:
>> Am 16.03.2016 um 13:09 schrieb Robin Murphy:
>>> On 16/03/16 11:39, Marc Zyngier wrote:
>>>> On 16/03/16 11:19, Bert Lindner wrote:
>>>>> Hopefully this is the correct place and way to report this.
>>
>> The main discussion is on netdev list actually, CC'ed.
>>
>>>>> For the board sun7i-a20-olinuxino-lime2, there seems to be a problem
>>>>> with the eth0 PHY in mainline kernel 4.5.0 that developed since
>>>>> 4.5.0-rc7. Ethernet does not work, although eth0 is reported:
>>>>>
>>>>> root@lime2-079f:~# ip a l eth0
>>>>> 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
>>>>> default qlen 1000
>>>>> link/ether 02:c9:05:02:07:9f brd ff:ff:ff:ff:ff:ff
>>>>>
>>>>> Difference reported in dmesg:
>>>>>
>>>>> 4.5.0-rc7:
>>>>> [ 9.379279] NET: Registered protocol family 10
>>>>> [ 10.217148] RX IPC Checksum Offload disabled
>>>>> [ 10.217195] No MAC Management Counters available
>>>>> [ 10.217627] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>>>>> [ 15.206250] sun7i-dwmac 1c50000.ethernet eth0: Link is Up -
>>>>> 1Gbps/Full - flow control off
>>>>> [ 15.206360] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>>>>
>>>>> 4.5.0:
>>>>> [ 9.767125] NET: Registered protocol family 10
>>>>> [ 10.357405] libphy: PHY stmmac-0:ffffffff not found
>>>>> [ 10.362382] eth0: Could not attach to PHY
>>>>> [ 10.366557] stmmac_open: Cannot attach to PHY (error: -19)
>>>>>
>>>>> .config is identical for both, also after make oldconfig, apart from
>>>>> comment with version number. DTB file is also identical between the two
>>>>> versions.
>>>>>
>>>>> Kernels are compiled on the board itself. /proc/version string:
>>>>> Linux version 4.5.0-rc7 (root@lime2-079f) (gcc version 4.9.1
>>>>> (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #1 SMP Mon Mar 7 11:57:25 UTC 2016
>>>>> Linux version 4.5.0 (root@lime2-079f) (gcc version 4.9.1 (Ubuntu/Linaro
>>>>> 4.9.1-16ubuntu6) ) #1 SMP Tue Mar 15 11:39:01 UTC 2016
>>>>>
>>>>> Please let me know if more info is needed, if I should post complete
>>>>> .config, test compile with a particular config or patch, etc. Part of
>>>>> .config below.
>>>>
>>>> Can you please try reverting 88f8b1b ("stmmac: Fix 'eth0: No PHY found'
>>>> regression") and report whether or not this changes anything? This seems
>>>> to be the only stmac patch between -rc7 and release...
>>>
>>> Sounds like the same thing as the giant ongoing discussion thread here:
>>>
>>> http://thread.gmane.org/gmane.linux.drivers.devicetree/159007/focus=402830
>>
>> v4 fixes for 4.5 are here:
>>
>> https://patchwork.ozlabs.org/patch/598195/ (revert)
>> https://patchwork.ozlabs.org/patch/598196/
>>
>> v2 fixes for linux-next here:
>>
>> https://patchwork.ozlabs.org/patch/598331/ (revert)
>> https://patchwork.ozlabs.org/patch/598332/
>>
>> Please let Peppe know whether they work for you guys.
>
> Hi guys - I can confirm 4.5.0 minus 88f8b1b works for me:
>
> root@lime2-079f:~# cat /proc/version
> Linux version 4.5.0-minus-88f8b1b (root@lime2-079f) (gcc version 4.9.1
> (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #2 SMP Wed Mar 16 12:50:03 UTC 2016
>
> From dmesg output:
> [ 9.731730] NET: Registered protocol family 10
> [ 10.516893] RX IPC Checksum Offload disabled
> [ 10.516948] No MAC Management Counters available
> [ 10.517374] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [ 15.505548] sun7i-dwmac 1c50000.ethernet eth0: Link is Up -
> 1Gbps/Full - flow control off
> [ 15.505660] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>
> .. and connected over ethernet.
Good to know, thanks. Could you also give the potential fix a go (as
mentioned by Andreas)? Just to make sure that whatever gets merged next
will actually fix the issue.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: linux-next: manual merge of the rdma tree with the net-next tree
From: Linus Torvalds @ 2016-03-16 17:44 UTC (permalink / raw)
To: Doug Ledford
Cc: Stephen Rothwell, David Miller, Network Development, linux-next,
Linux Kernel Mailing List, Amir Vadai, Maor Gottlieb
In-Reply-To: <56E99960.5000604@redhat.com>
On Wed, Mar 16, 2016 at 10:35 AM, Doug Ledford <dledford@redhat.com> wrote:
> On 3/16/2016 1:18 PM, Linus Torvalds wrote:
>> On Tue, Mar 15, 2016 at 5:58 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>> I fixed it up (see below) and can carry the fix as necessary (no action
>>> is required).
>>
>> Side note: can you change this wording for your manual merge script?
>> Last merge window (or was it the one before it?) we had confusion with
>> people who thought that "no action is required" means "you can just
>> ignore this entirely".
>
> I certainly didn't take it that way regardless of the wording.
It was Or Gerlitz. You were cc'd, since it was the whole rdma Mellanox
mess. I quote from that thread:
"> However, the fact that it got resolved in linux-next is purely
> informational. It doesn't "fix" the conflict - it just means that both
> sides should have gotten informed about it. That doesn't mean that the
> conflict goes away or becomes better.
That's news to me. When such things happen and caught by Stephen, we
are getting an email saying something like
"Today's linux-next merge of the infiniband tree got a conflict
between commit X from net-next tree and commit Y from the infiniband
tree. I fixed it up (see below) and can carry the fix as necessary (no
action is required)."
Also asked around a bit and got to learn on Stephen using git rerere,
so all (no action needed note + seeing git rerere in action...) that
leaded me to think that indeed no action is required from our side,
but after reading your email (twice, so far), I realized that this was
wrong conclusion."
So that whole "no action is required" wording very much has caused
confusion before in the rdma camp.
Let's fix the wording. I'm indeed hopeful that the rdma camp is now
keenly aware of the issues, but that doesn't change the fact that the
wording has been problematic.
Linus
^ permalink raw reply
* [PATCH] net: phy: at803x: don't depend on GPIOLIB
From: Sebastian Frias @ 2016-03-16 17:25 UTC (permalink / raw)
To: Uwe Kleine-König, David S. Miller, netdev; +Cc: lkml, mason
Commit 687908c2b649 ("net: phy: at803x: simplify using
devm_gpiod_get_optional and its 4th argument") introduced a dependency
on GPIOLIB that was not there before.
This commit removes such dependency by checking the return code and
comparing it against ENOSYS which is returned when GPIOLIB is not
selected.
Fixes: 687908c2b649 ("net: phy: at803x: simplify using
devm_gpiod_get_optional and its 4th argument")
Signed-off-by: Sebastian Frias <sf84@laposte.net>
---
drivers/net/phy/at803x.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 2174ec9..88b7ff3 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -252,7 +252,9 @@ static int at803x_probe(struct phy_device *phydev)
return -ENOMEM;
gpiod_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
- if (IS_ERR(gpiod_reset))
+ if (PTR_ERR(gpiod_reset) == -ENOSYS)
+ gpiod_reset = NULL;
+ else if (IS_ERR(gpiod_reset))
return PTR_ERR(gpiod_reset);
priv->gpiod_reset = gpiod_reset;
--
2.1.4
^ permalink raw reply related
* Re: [RFC v2 -next 1/2] virtio: Start feature MTU support
From: Stephen Hemminger @ 2016-03-16 18:23 UTC (permalink / raw)
To: Aaron Conole; +Cc: netdev, virtualization, linux-kernel, Michael S. Tsirkin
In-Reply-To: <1458075853-14789-2-git-send-email-aconole@redhat.com>
On Tue, 15 Mar 2016 17:04:12 -0400
Aaron Conole <aconole@redhat.com> wrote:
> --- a/include/uapi/linux/virtio_net.h
> +++ b/include/uapi/linux/virtio_net.h
> @@ -55,6 +55,7 @@
> #define VIRTIO_NET_F_MQ 22 /* Device supports Receive Flow
> * Steering */
> #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
> +#define VIRTIO_NET_F_MTU 25 /* Device supports Default MTU Negotiation */
>
> #ifndef VIRTIO_NET_NO_LEGACY
> #define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */
> @@ -73,6 +74,8 @@ struct virtio_net_config {
> * Legal values are between 1 and 0x8000
> */
> __u16 max_virtqueue_pairs;
> + /* Default maximum transmit unit advice */
> + __u16 mtu;
> } __attribute__((packed));
>
> /*
You can't change user visible headers without breaking ABI.
This structure might be used by other user code. Also how can this
work if host is using old size of structure.
^ permalink raw reply
* Re: [RFC v2 -next 1/2] virtio: Start feature MTU support
From: Michael S. Tsirkin @ 2016-03-16 18:29 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, linux-kernel, virtualization
In-Reply-To: <20160316112314.4510d386@samsung9>
On Wed, Mar 16, 2016 at 11:23:14AM -0700, Stephen Hemminger wrote:
> On Tue, 15 Mar 2016 17:04:12 -0400
> Aaron Conole <aconole@redhat.com> wrote:
>
> > --- a/include/uapi/linux/virtio_net.h
> > +++ b/include/uapi/linux/virtio_net.h
> > @@ -55,6 +55,7 @@
> > #define VIRTIO_NET_F_MQ 22 /* Device supports Receive Flow
> > * Steering */
> > #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
> > +#define VIRTIO_NET_F_MTU 25 /* Device supports Default MTU Negotiation */
> >
> > #ifndef VIRTIO_NET_NO_LEGACY
> > #define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */
> > @@ -73,6 +74,8 @@ struct virtio_net_config {
> > * Legal values are between 1 and 0x8000
> > */
> > __u16 max_virtqueue_pairs;
> > + /* Default maximum transmit unit advice */
> > + __u16 mtu;
> > } __attribute__((packed));
> >
> > /*
>
> You can't change user visible headers without breaking ABI.
> This structure might be used by other user code.
Then this userspace is broken.
If someone uses virtio code one has to follow virtio spec.
And Virtio spec makes it very clear that
1. config space size can change at any time
2. fields can only be accessed if the correct feature bit
has been both advertized in host bitmap and acknowledged
in guest bitmap
> Also how can this
> work if host is using old size of structure.
It works because access is guarded by feature bit check.
--
MST
^ permalink raw reply
* [PATCH] bridge:Fix incorrect variable assignment on error path in br_sysfs_addbr
From: Nicholas Krause @ 2016-03-16 18:31 UTC (permalink / raw)
To: stephen; +Cc: netdev, bridge, davem, linux-kernel
This fixes the incorrect variable assignment on error path in
br_sysfs_addbr for when the call to kobject_create_and_add
fails to assign the value of -EINVAL to the returned variable of
err rather then incorrectly return zero making callers think this
function has succeededed due to the previous assignment being
assigned zero when assigning it the successful return value of
the call to sysfs_create_group which is zero.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
---
net/bridge/br_sysfs_br.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c
index 6b80914..6833d25 100644
--- a/net/bridge/br_sysfs_br.c
+++ b/net/bridge/br_sysfs_br.c
@@ -872,6 +872,7 @@ int br_sysfs_addbr(struct net_device *dev)
if (!br->ifobj) {
pr_info("%s: can't add kobject (directory) %s/%s\n",
__func__, dev->name, SYSFS_BRIDGE_PORT_SUBDIR);
+ err = -EINVAL;
goto out3;
}
return 0;
--
2.5.0
^ permalink raw reply related
* Re: [RFCv2 0/3] mac80211: implement fq codel
From: Dave Taht @ 2016-03-16 18:36 UTC (permalink / raw)
To: Michal Kazior
Cc: Network Development, codel@lists.bufferbloat.net, linux-wireless,
ath10k@lists.infradead.org, make-wifi-fast
In-Reply-To: <CAA93jw5cUaj_qM+CYHHoRaghLDLC+BUgF4AjT=Oec+SB-zb74g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2224 bytes --]
That is the sanest 802.11e queue behavior I have ever seen! (at both
6 and 300mbit! in the ath10k patched mac test)
It would be good to add a flow to this test that exercises the VI
queue (CS5 diffserv marking?), and to repeat this test with wmm
disabled for comparison.
Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi
On Wed, Mar 16, 2016 at 8:37 AM, Dave Taht <dave.taht@gmail.com> wrote:
> it is helpful to name the test files coherently in the flent tests, in
> addition to using a directory structure and timestamp. It makes doing
> comparison plots in data->add-other-open-data-files simpler. "-t
> patched-mac-300mbps", for example.
>
> Also netperf from svn (maybe 2.7, don't remember) will restart udp_rr
> after a packet loss in 250ms. Seeing a loss on UDP_RR and it stop for
> a while is "ok".
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> https://www.gofundme.com/savewifi
>
>
> On Wed, Mar 16, 2016 at 3:26 AM, Michal Kazior <michal.kazior@tieto.com> wrote:
>> On 16 March 2016 at 11:17, Michal Kazior <michal.kazior@tieto.com> wrote:
>>> Hi,
>>>
>>> Most notable changes:
>> [...]
>>> * ath10k proof-of-concept that uses the new tx
>>> scheduling (will post results in separate
>>> email)
>>
>> I'm attaching a bunch of tests I've done using flent. They are all
>> "burst" tests with burst-ports=1 and burst-length=2. The testing
>> topology is:
>>
>> AP ----> STA
>> AP )) (( STA
>> [veth]--[br]--[wlan] )) (( [wlan]
>>
>> You can notice that in some tests plot data gets cut-off. There are 2
>> problems I've identified:
>> - excess drops (not a problem with the patchset and can be seen when
>> there's no codel-in-mac or scheduling isn't used)
>> - UDP_RR hangs (apparently QCA99X0 I have hangs for a few hundred ms
>> sometimes at times and doesn't Rx frames causing UDP_RR to stop
>> mid-way; confirmed with logs and sniffer; I haven't figured out *why*
>> exactly, could be some hw/fw quirk)
>>
>> Let me know if you have questions or comments regarding my testing/results.
>>
>>
>> Michał
[-- Attachment #2: sanest_802.11eresult_i_have_ever_seen.png --]
[-- Type: image/png, Size: 146956 bytes --]
[-- Attachment #3: Type: text/plain, Size: 140 bytes --]
_______________________________________________
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
^ permalink raw reply
* [PATCH net-next v4 0/2] RDS: TCP: tunable socket buffer parameters
From: Sowmini Varadhan @ 2016-03-16 18:38 UTC (permalink / raw)
To: netdev; +Cc: davem, sowmini.varadhan, santosh.shilimkar, hannes, eric.dumazet
Patch 1 uses sysctl to create tunable socket buffer size parameters.
Patch 2 removes an unuused constant.
v2: use sysctl
v3: review comments from Santosh Shilimkar, Eric Dumazet
v4: review comments from Hannes Sowa
Sowmini Varadhan (2):
RDS: TCP: Add sysctl tunables for sndbuf/rcvbuf on rds-tcp socket
RDS: TCP: Remove unused constant
net/rds/tcp.c | 145 ++++++++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 134 insertions(+), 11 deletions(-)
^ permalink raw reply
* [PATCH net-next v4 2/2] RDS: TCP: Remove unused constant
From: Sowmini Varadhan @ 2016-03-16 18:38 UTC (permalink / raw)
To: netdev; +Cc: davem, sowmini.varadhan, santosh.shilimkar, hannes, eric.dumazet
In-Reply-To: <cover.1458152608.git.sowmini.varadhan@oracle.com>
RDS_TCP_DEFAULT_BUFSIZE has been unused since commit 1edd6a14d24f
("RDS-TCP: Do not bloat sndbuf/rcvbuf in rds_tcp_tune").
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
---
v3: review comments from Santosh Shilimkar
net/rds/tcp.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/net/rds/tcp.c b/net/rds/tcp.c
index 3802785..61ed2a8 100644
--- a/net/rds/tcp.c
+++ b/net/rds/tcp.c
@@ -52,8 +52,6 @@ static LIST_HEAD(rds_tcp_conn_list);
static struct kmem_cache *rds_tcp_conn_slab;
-#define RDS_TCP_DEFAULT_BUFSIZE (128 * 1024)
-
static int rds_tcp_skbuf_handler(struct ctl_table *ctl, int write,
void __user *buffer, size_t *lenp,
loff_t *fpos);
--
1.7.1
^ permalink raw reply related
* [PATCH net-next v4 1/2] RDS: TCP: Add sysctl tunables for sndbuf/rcvbuf on rds-tcp socket
From: Sowmini Varadhan @ 2016-03-16 18:38 UTC (permalink / raw)
To: netdev; +Cc: davem, sowmini.varadhan, santosh.shilimkar, hannes, eric.dumazet
In-Reply-To: <cover.1458152608.git.sowmini.varadhan@oracle.com>
Add per-net sysctl tunables to set the size of sndbuf and
rcvbuf on the kernel tcp socket.
The tunables are added at /proc/sys/net/rds/tcp/rds_tcp_sndbuf
and /proc/sys/net/rds/tcp/rds_tcp_rcvbuf.
These values must be set before accept() or connect(),
and there may be an arbitrary number of existing rds-tcp
sockets when the tunable is modified. To make sure that all
connections in the netns pick up the same value for the tunable,
we reset existing rds-tcp connections in the netns, so that
they can reconnect with the new parameters.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
---
v2; use sysctl instead of module param. Tunabes are now per netns,
and can be dynamically modified without restarting all namespaces.
v3: review comments from Santosh Shilimkar. Sockbuf size comments from
Eric Dumazet
v4: review comments from Hannes Sowa
net/rds/tcp.c | 145 +++++++++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 135 insertions(+), 10 deletions(-)
diff --git a/net/rds/tcp.c b/net/rds/tcp.c
index ad60299..3802785 100644
--- a/net/rds/tcp.c
+++ b/net/rds/tcp.c
@@ -54,6 +54,35 @@ static struct kmem_cache *rds_tcp_conn_slab;
#define RDS_TCP_DEFAULT_BUFSIZE (128 * 1024)
+static int rds_tcp_skbuf_handler(struct ctl_table *ctl, int write,
+ void __user *buffer, size_t *lenp,
+ loff_t *fpos);
+
+int rds_tcp_min_sndbuf = SOCK_MIN_SNDBUF;
+int rds_tcp_min_rcvbuf = SOCK_MIN_RCVBUF;
+
+static struct ctl_table rds_tcp_sysctl_table[] = {
+#define RDS_TCP_SNDBUF 0
+ {
+ .procname = "rds_tcp_sndbuf",
+ /* data is per-net pointer */
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = rds_tcp_skbuf_handler,
+ .extra1 = &rds_tcp_min_sndbuf,
+ },
+#define RDS_TCP_RCVBUF 1
+ {
+ .procname = "rds_tcp_rcvbuf",
+ /* data is per-net pointer */
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = rds_tcp_skbuf_handler,
+ .extra1 = &rds_tcp_min_rcvbuf,
+ },
+ { }
+};
+
/* doing it this way avoids calling tcp_sk() */
void rds_tcp_nonagle(struct socket *sock)
{
@@ -66,15 +95,6 @@ void rds_tcp_nonagle(struct socket *sock)
set_fs(oldfs);
}
-/* All module specific customizations to the RDS-TCP socket should be done in
- * rds_tcp_tune() and applied after socket creation. In general these
- * customizations should be tunable via module_param()
- */
-void rds_tcp_tune(struct socket *sock)
-{
- rds_tcp_nonagle(sock);
-}
-
u32 rds_tcp_snd_nxt(struct rds_tcp_connection *tc)
{
return tcp_sk(tc->t_sock->sk)->snd_nxt;
@@ -272,8 +292,34 @@ static int rds_tcp_netid;
struct rds_tcp_net {
struct socket *rds_tcp_listen_sock;
struct work_struct rds_tcp_accept_w;
+ struct ctl_table_header *rds_tcp_sysctl;
+ struct ctl_table *ctl_table;
+ int sndbuf_size;
+ int rcvbuf_size;
};
+/* All module specific customizations to the RDS-TCP socket should be done in
+ * rds_tcp_tune() and applied after socket creation.
+ */
+void rds_tcp_tune(struct socket *sock)
+{
+ struct sock *sk = sock->sk;
+ struct net *net = sock_net(sk);
+ struct rds_tcp_net *rtn = net_generic(net, rds_tcp_netid);
+
+ rds_tcp_nonagle(sock);
+ lock_sock(sk);
+ if (rtn->sndbuf_size > 0) {
+ sk->sk_sndbuf = rtn->sndbuf_size;
+ sk->sk_userlocks |= SOCK_SNDBUF_LOCK;
+ }
+ if (rtn->rcvbuf_size > 0) {
+ sk->sk_sndbuf = rtn->rcvbuf_size;
+ sk->sk_userlocks |= SOCK_RCVBUF_LOCK;
+ }
+ release_sock(sk);
+}
+
static void rds_tcp_accept_worker(struct work_struct *work)
{
struct rds_tcp_net *rtn = container_of(work,
@@ -295,20 +341,60 @@ void rds_tcp_accept_work(struct sock *sk)
static __net_init int rds_tcp_init_net(struct net *net)
{
struct rds_tcp_net *rtn = net_generic(net, rds_tcp_netid);
+ struct ctl_table *tbl;
+ int err = 0;
+ memset(rtn, 0, sizeof(*rtn));
+
+ /* {snd, rcv}buf_size default to 0, which implies we let the
+ * stack pick the value, and permit auto-tuning of buffer size.
+ */
+ if (net == &init_net) {
+ tbl = rds_tcp_sysctl_table;
+ } else {
+ tbl = kmemdup(rds_tcp_sysctl_table,
+ sizeof(rds_tcp_sysctl_table), GFP_KERNEL);
+ if (!tbl) {
+ pr_warn("could not set allocate syctl table\n");
+ return -ENOMEM;
+ }
+ rtn->ctl_table = tbl;
+ }
+ tbl[RDS_TCP_SNDBUF].data = &rtn->sndbuf_size;
+ tbl[RDS_TCP_RCVBUF].data = &rtn->rcvbuf_size;
+ rtn->rds_tcp_sysctl = register_net_sysctl(net, "net/rds/tcp", tbl);
+ if (!rtn->rds_tcp_sysctl) {
+ pr_warn("could not register sysctl\n");
+ err = -ENOMEM;
+ goto fail;
+ }
rtn->rds_tcp_listen_sock = rds_tcp_listen_init(net);
if (!rtn->rds_tcp_listen_sock) {
pr_warn("could not set up listen sock\n");
- return -EAFNOSUPPORT;
+ unregister_net_sysctl_table(rtn->rds_tcp_sysctl);
+ rtn->rds_tcp_sysctl = NULL;
+ err = -EAFNOSUPPORT;
+ goto fail;
}
INIT_WORK(&rtn->rds_tcp_accept_w, rds_tcp_accept_worker);
return 0;
+
+fail:
+ if (net != &init_net)
+ kfree(tbl);
+ return err;
}
static void __net_exit rds_tcp_exit_net(struct net *net)
{
struct rds_tcp_net *rtn = net_generic(net, rds_tcp_netid);
+ if (rtn->rds_tcp_sysctl)
+ unregister_net_sysctl_table(rtn->rds_tcp_sysctl);
+
+ if (net != &init_net && rtn->ctl_table)
+ kfree(rtn->ctl_table);
+
/* If rds_tcp_exit_net() is called as a result of netns deletion,
* the rds_tcp_kill_sock() device notifier would already have cleaned
* up the listen socket, thus there is no work to do in this function.
@@ -383,6 +469,45 @@ static struct notifier_block rds_tcp_dev_notifier = {
.priority = -10, /* must be called after other network notifiers */
};
+/* when sysctl is used to modify some kernel socket parameters,this
+ * function resets the RDS connections in that netns so that we can
+ * restart with new parameters. The assumption is that such reset
+ * events are few and far-between.
+ */
+static void rds_tcp_sysctl_reset(struct net *net)
+{
+ struct rds_tcp_connection *tc, *_tc;
+
+ spin_lock_irq(&rds_tcp_conn_lock);
+ list_for_each_entry_safe(tc, _tc, &rds_tcp_conn_list, t_tcp_node) {
+ struct net *c_net = read_pnet(&tc->conn->c_net);
+
+ if (net != c_net || !tc->t_sock)
+ continue;
+
+ rds_conn_drop(tc->conn); /* reconnect with new parameters */
+ }
+ spin_unlock_irq(&rds_tcp_conn_lock);
+}
+
+static int rds_tcp_skbuf_handler(struct ctl_table *ctl, int write,
+ void __user *buffer, size_t *lenp,
+ loff_t *fpos)
+{
+ struct net *net = current->nsproxy->net_ns;
+ int err;
+
+ err = proc_dointvec_minmax(ctl, write, buffer, lenp, fpos);
+ if (err < 0) {
+ pr_warn("Invalid input. Must be >= %d\n",
+ *(int *)(ctl->extra1));
+ return err;
+ }
+ if (write)
+ rds_tcp_sysctl_reset(net);
+ return 0;
+}
+
static void rds_tcp_exit(void)
{
rds_info_deregister_func(RDS_INFO_TCP_SOCKETS, rds_tcp_tc_info);
--
1.7.1
^ permalink raw reply related
* Re: [RFCv2 0/3] mac80211: implement fq codel
From: Bob Copeland @ 2016-03-16 18:55 UTC (permalink / raw)
To: Dave Taht
Cc: Michal Kazior, linux-wireless,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Network Development,
make-wifi-fast-JXvr2/1DY2fm6VMwtOF2vx4hnT+Y9+D1,
codel-JXvr2/1DY2fm6VMwtOF2vx4hnT+Y9+D1@public.gmane.org
In-Reply-To: <CAA93jw6tDdiYuginPbUY1DFJLiDxofHMFN6j2BvQPabPmBtuRw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Mar 16, 2016 at 11:36:31AM -0700, Dave Taht wrote:
> That is the sanest 802.11e queue behavior I have ever seen! (at both
> 6 and 300mbit! in the ath10k patched mac test)
Out of curiosity, why does BE have larger latency than BK in that chart?
I'd have expected the opposite.
--
Bob Copeland %% http://bobcopeland.com/
--
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: [RFCv2 0/3] mac80211: implement fq codel
From: Jasmine Strong @ 2016-03-16 19:48 UTC (permalink / raw)
To: Bob Copeland
Cc: Network Development, linux-wireless, ath10k@lists.infradead.org,
codel@lists.bufferbloat.net, make-wifi-fast
In-Reply-To: <20160316185531.GA1771@localhost>
[-- Attachment #1.1: Type: text/plain, Size: 634 bytes --]
BK usually has 0 txop, so it doesn't do aggregation.
On Wed, Mar 16, 2016 at 11:55 AM, Bob Copeland <me@bobcopeland.com> wrote:
> On Wed, Mar 16, 2016 at 11:36:31AM -0700, Dave Taht wrote:
> > That is the sanest 802.11e queue behavior I have ever seen! (at both
> > 6 and 300mbit! in the ath10k patched mac test)
>
> Out of curiosity, why does BE have larger latency than BK in that chart?
> I'd have expected the opposite.
>
> --
> Bob Copeland %% http://bobcopeland.com/
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>
[-- Attachment #1.2: Type: text/html, Size: 1329 bytes --]
[-- Attachment #2: Type: text/plain, Size: 140 bytes --]
_______________________________________________
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
^ permalink raw reply
* ksoftirqd and network processing
From: Anna Fischer @ 2016-03-16 19:57 UTC (permalink / raw)
To: netdev
In-Reply-To: <56E98F4C.4000004@sirrix.com>
Hi there,
I'd like to understand more in detail how ksoftirqd works in combination
with Linux kernel networking.
I'm doing IPSec processing on my Linux machine (kernel 4.4). On one
interface I receive encrypted packets which are decrypted and then
routed out plaintext (TCP) via another interface. Now I can
see that ksoftirqd runs at 100% CPU. Furthermore, I see that initially
it runs on core 0, then after a few seconds, it switches over to core 1
and runs at 100%, then switches over to core 2, and so on.
I have two questions:
1) I assume it switches cores because the kernel thread is scheduled on
different cores, depending on where the softirqs happen. Why does the
load never scale across cores? As far as I understand softirqs can run
concurrently on different cores. So why does it not scale?
2) Is it normal that ksoftirqd runs at such a high CPU load when doing
IPSec, if the core is a small core with small frequency (Intel Atoms,
for example)? And if so, is there any way to optimize this for IPSec?
3) When I pin RX queue interrupts of the NIC to certain cores, I can see
that interrupts are really only processed on that core. However, it does
not change anything about the ksoftirqd behavior. Should it not match,
how I route interrupts?
Many thanks,
Anna
^ permalink raw reply
* Re: [PATCH v2] netfilter: fix race condition in ipset save, swap and delete
From: Jozsef Kadlecsik @ 2016-03-16 20:35 UTC (permalink / raw)
To: Vishwanath Pai; +Cc: pablo, kaber, netfilter-devel, coreteam, johunt, netdev
In-Reply-To: <20160314195446.GA3642@akamai.com>
Hi,
On Mon, 14 Mar 2016, Vishwanath Pai wrote:
> I have updated the patch according to comments by Jozsef. Renamed
> ref_kernel to ref_netlink, renamed _put/_get functions and updated the
> description in commit log.
Patch is applied to the ipset git tree - you use some older kernel tree
and I had to apply it manually. I'll send the patch for kernel inclusion.
Best regards,
Jozsef
> --
>
> netfilter: fix race condition in ipset save, swap and delete
>
> This fix adds a new reference counter (ref_netlink) for the struct ip_set.
> The other reference counter (ref) can be swapped out by ip_set_swap and we
> need a separate counter to keep track of references for netlink events
> like dump. Using the same ref counter for dump causes a race condition
> which can be demonstrated by the following script:
>
> #!/bin/sh
> ipset create hash_ip1 hash:ip family inet hashsize 1024 maxelem 500000 \
> counters
> ipset create hash_ip2 hash:ip family inet hashsize 300000 maxelem 500000 \
> counters
> ipset create hash_ip3 hash:ip family inet hashsize 1024 maxelem 500000 \
> counters
>
> ipset save &
>
> ipset swap hash_ip3 hash_ip2
> ipset destroy hash_ip3 /* will crash the machine */
>
> Swap will exchange the values of ref so destroy will see ref = 0 instead of
> ref = 1. With this fix in place swap will not succeed because ipset save
> still has ref_netlink on the set (ip_set_swap doesn't swap ref_netlink).
>
> Both delete and swap will error out if ref_netlink != 0 on the set.
>
> Note: The changes to *_head functions is because previously we would
> increment ref whenever we called these functions, we don't do that
> anymore.
>
> Reviewed-by: Joshua Hunt <johunt@akamai.com>
> Signed-off-by: Vishwanath Pai <vpai@akamai.com>
>
> --
>
> diff --git a/include/linux/netfilter/ipset/ip_set.h b/include/linux/netfilter/ipset/ip_set.h
> index 0e1f433..f48b8a6 100644
> --- a/include/linux/netfilter/ipset/ip_set.h
> +++ b/include/linux/netfilter/ipset/ip_set.h
> @@ -234,6 +234,10 @@ struct ip_set {
> spinlock_t lock;
> /* References to the set */
> u32 ref;
> + /* References to the set for netlink events like dump,
> + * ref can be swapped out by ip_set_swap
> + */
> + u32 ref_netlink;
> /* The core set type */
> struct ip_set_type *type;
> /* The type variant doing the real job */
> diff --git a/net/netfilter/ipset/ip_set_bitmap_gen.h b/net/netfilter/ipset/ip_set_bitmap_gen.h
> index b0bc475..2e8e7e5 100644
> --- a/net/netfilter/ipset/ip_set_bitmap_gen.h
> +++ b/net/netfilter/ipset/ip_set_bitmap_gen.h
> @@ -95,7 +95,7 @@ mtype_head(struct ip_set *set, struct sk_buff *skb)
> if (!nested)
> goto nla_put_failure;
> if (mtype_do_head(skb, map) ||
> - nla_put_net32(skb, IPSET_ATTR_REFERENCES, htonl(set->ref - 1)) ||
> + nla_put_net32(skb, IPSET_ATTR_REFERENCES, htonl(set->ref)) ||
> nla_put_net32(skb, IPSET_ATTR_MEMSIZE, htonl(memsize)))
> goto nla_put_failure;
> if (unlikely(ip_set_put_flags(skb, set)))
> diff --git a/net/netfilter/ipset/ip_set_core.c b/net/netfilter/ipset/ip_set_core.c
> index 95db43f..a558075 100644
> --- a/net/netfilter/ipset/ip_set_core.c
> +++ b/net/netfilter/ipset/ip_set_core.c
> @@ -497,6 +497,26 @@ __ip_set_put(struct ip_set *set)
> write_unlock_bh(&ip_set_ref_lock);
> }
>
> +/* set->ref can be swapped out by ip_set_swap, netlink events (like dump) need
> + * a separate reference counter
> + */
> +static inline void
> +__ip_set_get_netlink(struct ip_set *set)
> +{
> + write_lock_bh(&ip_set_ref_lock);
> + set->ref_netlink++;
> + write_unlock_bh(&ip_set_ref_lock);
> +}
> +
> +static inline void
> +__ip_set_put_netlink(struct ip_set *set)
> +{
> + write_lock_bh(&ip_set_ref_lock);
> + BUG_ON(set->ref_netlink == 0);
> + set->ref_netlink--;
> + write_unlock_bh(&ip_set_ref_lock);
> +}
> +
> /* Add, del and test set entries from kernel.
> *
> * The set behind the index must exist and must be referenced
> @@ -999,7 +1019,7 @@ static int ip_set_destroy(struct net *net, struct sock *ctnl,
> if (!attr[IPSET_ATTR_SETNAME]) {
> for (i = 0; i < inst->ip_set_max; i++) {
> s = ip_set(inst, i);
> - if (s && s->ref) {
> + if (s && (s->ref || s->ref_netlink)) {
> ret = -IPSET_ERR_BUSY;
> goto out;
> }
> @@ -1021,7 +1041,7 @@ static int ip_set_destroy(struct net *net, struct sock *ctnl,
> if (!s) {
> ret = -ENOENT;
> goto out;
> - } else if (s->ref) {
> + } else if (s->ref || s->ref_netlink) {
> ret = -IPSET_ERR_BUSY;
> goto out;
> }
> @@ -1168,6 +1188,9 @@ static int ip_set_swap(struct net *net, struct sock *ctnl, struct sk_buff *skb,
> from->family == to->family))
> return -IPSET_ERR_TYPE_MISMATCH;
>
> + if (from->ref_netlink || to->ref_netlink)
> + return -EBUSY;
> +
> strncpy(from_name, from->name, IPSET_MAXNAMELEN);
> strncpy(from->name, to->name, IPSET_MAXNAMELEN);
> strncpy(to->name, from_name, IPSET_MAXNAMELEN);
> @@ -1203,7 +1226,7 @@ ip_set_dump_done(struct netlink_callback *cb)
> if (set->variant->uref)
> set->variant->uref(set, cb, false);
> pr_debug("release set %s\n", set->name);
> - __ip_set_put_byindex(inst, index);
> + __ip_set_put_netlink(set);
> }
> return 0;
> }
> @@ -1325,7 +1348,7 @@ dump_last:
> if (!cb->args[IPSET_CB_ARG0]) {
> /* Start listing: make sure set won't be destroyed */
> pr_debug("reference set\n");
> - set->ref++;
> + set->ref_netlink++;
> }
> write_unlock_bh(&ip_set_ref_lock);
> nlh = start_msg(skb, NETLINK_CB(cb->skb).portid,
> @@ -1393,7 +1416,7 @@ release_refcount:
> if (set->variant->uref)
> set->variant->uref(set, cb, false);
> pr_debug("release set %s\n", set->name);
> - __ip_set_put_byindex(inst, index);
> + __ip_set_put_netlink(set);
> cb->args[IPSET_CB_ARG0] = 0;
> }
> out:
> diff --git a/net/netfilter/ipset/ip_set_hash_gen.h b/net/netfilter/ipset/ip_set_hash_gen.h
> index e5336ab..d32fd6b 100644
> --- a/net/netfilter/ipset/ip_set_hash_gen.h
> +++ b/net/netfilter/ipset/ip_set_hash_gen.h
> @@ -1082,7 +1082,7 @@ mtype_head(struct ip_set *set, struct sk_buff *skb)
> if (nla_put_u32(skb, IPSET_ATTR_MARKMASK, h->markmask))
> goto nla_put_failure;
> #endif
> - if (nla_put_net32(skb, IPSET_ATTR_REFERENCES, htonl(set->ref - 1)) ||
> + if (nla_put_net32(skb, IPSET_ATTR_REFERENCES, htonl(set->ref)) ||
> nla_put_net32(skb, IPSET_ATTR_MEMSIZE, htonl(memsize)))
> goto nla_put_failure;
> if (unlikely(ip_set_put_flags(skb, set)))
> diff --git a/net/netfilter/ipset/ip_set_list_set.c b/net/netfilter/ipset/ip_set_list_set.c
> index bbede95..00f92ae 100644
> --- a/net/netfilter/ipset/ip_set_list_set.c
> +++ b/net/netfilter/ipset/ip_set_list_set.c
> @@ -457,7 +457,7 @@ list_set_head(struct ip_set *set, struct sk_buff *skb)
> if (!nested)
> goto nla_put_failure;
> if (nla_put_net32(skb, IPSET_ATTR_SIZE, htonl(map->size)) ||
> - nla_put_net32(skb, IPSET_ATTR_REFERENCES, htonl(set->ref - 1)) ||
> + nla_put_net32(skb, IPSET_ATTR_REFERENCES, htonl(set->ref)) ||
> nla_put_net32(skb, IPSET_ATTR_MEMSIZE,
> htonl(sizeof(*map) + n * set->dsize)))
> goto nla_put_failure;
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply
* Re: linux-next: manual merge of the rdma tree with the net-next tree
From: Stephen Rothwell @ 2016-03-16 20:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: Doug Ledford, David Miller, Network Development, linux-next,
Linux Kernel Mailing List, Amir Vadai, Maor Gottlieb
In-Reply-To: <CA+55aFzhYJxCOXER-mhOfJ6=V13Rb5F0LB_3A9n7S_dLkb8f0g@mail.gmail.com>
Hi Linus,
On Wed, 16 Mar 2016 10:18:33 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On Tue, Mar 15, 2016 at 5:58 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required).
>
> Side note: can you change this wording for your manual merge script?
> Last merge window (or was it the one before it?) we had confusion with
> people who thought that "no action is required" means "you can just
> ignore this entirely".
>
> I want people who have known merge issues to at the very least
> *mention* them to me when they send the pull request, and I also think
> that trees that have merge conflicts that aren't just totally trivial
> should also make sure that they have communicated with each other
> about why the problem happened.
>
> This is *particularly* true for the complete effing disaster that is
> mellanox and rdma-vs-networking.
>
> So please don't say "no action is required". Please make it clear that
> there may not be any further action needed for linux-next itself, but
> that other action may certainly be required.
Yeah, I can see your point. The "no action required" was a reaction to
people going off and rebasing their tree or dropping patches at any
sign of a conflict at all.
How about "This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may want also want to
consider cooperate with the maintainer of the conflicting tree to
minimise any particularly complex conflicts."
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: manual merge of the rdma tree with the net-next tree
From: Linus Torvalds @ 2016-03-16 21:01 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Doug Ledford, David Miller, Network Development, linux-next,
Linux Kernel Mailing List, Amir Vadai, Maor Gottlieb
In-Reply-To: <20160317075246.39a08e61@canb.auug.org.au>
On Wed, Mar 16, 2016 at 1:52 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> How about "This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may want also want to
> consider cooperate with the maintainer of the conflicting tree to
> minimise any particularly complex conflicts."
Yup, sounds fine.
Maybe you could even say "don't merge this to hide the problem",
because that has been another reaction in the past, but the above
already sounds pretty good.
Linus
^ permalink raw reply
* Re: linux-next: manual merge of the rdma tree with the net-next tree
From: Andrew Lunn @ 2016-03-16 21:15 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linus Torvalds, Doug Ledford, David Miller, Network Development,
linux-next, Linux Kernel Mailing List, Amir Vadai, Maor Gottlieb
In-Reply-To: <20160317075246.39a08e61@canb.auug.org.au>
Hi Stephen
> How about "This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may want also want to
Only the second want is required.
> consider cooperate with the maintainer of the conflicting tree to
cooperating
Andrew
^ permalink raw reply
* [iproute PATCH 0/4] tc: pedit: further fixes
From: Phil Sutter @ 2016-03-16 21:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jamal Hadi Salim, netdev
The following series was created after testing pedit on a big-endian
system. It starts with a patch fixing coding style in tc/p_ip.c, then the
actual big-endian fixup, a fix for raw op discovered when writing the
pedit test for testsuite and finally the actual testsuite addon.
Phil Sutter (4):
tc/p_ip.c: Lint through checkpatch.pl
tc: pedit: Fix for big-endian systems
tc: pedit: Fix raw op
testsuite: add a test for tc pedit action
tc/m_pedit.c | 23 ++---
tc/p_ip.c | 38 ++++----
testsuite/tests/tc/pedit.t | 217 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 250 insertions(+), 28 deletions(-)
create mode 100755 testsuite/tests/tc/pedit.t
--
2.7.2
^ permalink raw reply
* [iproute PATCH 2/4] tc: pedit: Fix for big-endian systems
From: Phil Sutter @ 2016-03-16 21:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jamal Hadi Salim, netdev
In-Reply-To: <1458164915-31802-1-git-send-email-phil@nwl.cc>
This was tricky to get right:
- The 'stride' value used for 8 and 16 bit values must behave inverse to
the value's intra word offset to work correctly with big-endian data
act_pedit is editing.
- The 'm' array's values are in host byte order, so they have to be
converted as well (and the ordering was just inverse, for some
reason).
- The only sane way of getting this right is to manipulate value/mask in
host byte order and convert the output.
- TIPV4 (i.e. 'munge ip src/dst') had it's own pitfall: the address
parser converts to network byte order automatically. This patch fixes
this by converting it back before calling pack_key32, which is a hack
but at least does not require to implement a completely separate code
flow.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
tc/m_pedit.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/tc/m_pedit.c b/tc/m_pedit.c
index a7960d524c29a..7de47800040bc 100644
--- a/tc/m_pedit.c
+++ b/tc/m_pedit.c
@@ -160,7 +160,7 @@ int
pack_key16(__u32 retain,struct tc_pedit_sel *sel,struct tc_pedit_key *tkey)
{
int ind, stride;
- __u32 m[4] = {0xFFFF0000,0xFF0000FF,0x0000FFFF};
+ __u32 m[4] = {0x0000FFFF,0xFF0000FF,0xFFFF0000};
if (tkey->val > 0xFFFF || tkey->mask > 0xFFFF) {
fprintf(stderr, "pack_key16 bad value\n");
@@ -174,9 +174,9 @@ pack_key16(__u32 retain,struct tc_pedit_sel *sel,struct tc_pedit_key *tkey)
return -1;
}
- stride = 8 * ind;
- tkey->val = htons(tkey->val & retain) << stride;
- tkey->mask = (htons(tkey->mask | ~retain) << stride) | m[ind];
+ stride = 8 * (2 - ind);
+ tkey->val = htonl((tkey->val & retain) << stride);
+ tkey->mask = htonl(((tkey->mask | ~retain) << stride) | m[ind]);
tkey->off &= ~3;
@@ -190,7 +190,7 @@ int
pack_key8(__u32 retain,struct tc_pedit_sel *sel,struct tc_pedit_key *tkey)
{
int ind, stride;
- __u32 m[4] = {0xFFFFFF00,0xFFFF00FF,0xFF00FFFF,0x00FFFFFF};
+ __u32 m[4] = {0x00FFFFFF,0xFF00FFFF,0xFFFF00FF,0xFFFFFF00};
if (tkey->val > 0xFF || tkey->mask > 0xFF) {
fprintf(stderr, "pack_key8 bad value (val %x mask %x\n", tkey->val, tkey->mask);
@@ -199,9 +199,9 @@ pack_key8(__u32 retain,struct tc_pedit_sel *sel,struct tc_pedit_key *tkey)
ind = tkey->off & 3;
- stride = 8 * ind;
- tkey->val = (tkey->val & retain) << stride;
- tkey->mask = ((tkey->mask | ~retain) << stride) | m[ind];
+ stride = 8 * (3 - ind);
+ tkey->val = htonl((tkey->val & retain) << stride);
+ tkey->mask = htonl(((tkey->mask | ~retain) << stride) | m[ind]);
tkey->off &= ~3;
@@ -286,6 +286,9 @@ parse_cmd(int *argc_p, char ***argv_p, __u32 len, int type,__u32 retain,struct t
tkey->val = val;
tkey->mask = mask;
+ if (type == TIPV4)
+ tkey->val = ntohl(tkey->val);
+
if (len == 1) {
res = pack_key8(retain,sel,tkey);
goto done;
--
2.7.2
^ permalink raw reply related
* [iproute PATCH 1/4] tc/p_ip.c: Lint through checkpatch.pl
From: Phil Sutter @ 2016-03-16 21:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jamal Hadi Salim, netdev
In-Reply-To: <1458164915-31802-1-git-send-email-phil@nwl.cc>
This diff was generated by using the fix-inplace option of checkpatch.pl
and breaking the overlong lines of parse_ip() and parse_ip6()
signatures.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
tc/p_ip.c | 38 ++++++++++++++++++++------------------
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/tc/p_ip.c b/tc/p_ip.c
index 10e4bebc71d94..535151e5d7668 100644
--- a/tc/p_ip.c
+++ b/tc/p_ip.c
@@ -24,7 +24,8 @@
#include "m_pedit.h"
static int
-parse_ip(int *argc_p, char ***argv_p,struct tc_pedit_sel *sel,struct tc_pedit_key *tkey)
+parse_ip(int *argc_p, char ***argv_p,
+ struct tc_pedit_sel *sel, struct tc_pedit_key *tkey)
{
int res = -1;
int argc = *argc_p;
@@ -36,13 +37,13 @@ parse_ip(int *argc_p, char ***argv_p,struct tc_pedit_sel *sel,struct tc_pedit_ke
if (strcmp(*argv, "src") == 0) {
NEXT_ARG();
tkey->off = 12;
- res = parse_cmd(&argc, &argv, 4, TIPV4,RU32,sel,tkey);
+ res = parse_cmd(&argc, &argv, 4, TIPV4, RU32, sel, tkey);
goto done;
}
if (strcmp(*argv, "dst") == 0) {
NEXT_ARG();
tkey->off = 16;
- res = parse_cmd(&argc, &argv, 4, TIPV4,RU32,sel,tkey);
+ res = parse_cmd(&argc, &argv, 4, TIPV4, RU32, sel, tkey);
goto done;
}
/* jamal - look at these and make them either old or new
@@ -52,94 +53,95 @@ parse_ip(int *argc_p, char ***argv_p,struct tc_pedit_sel *sel,struct tc_pedit_ke
if (strcmp(*argv, "tos") == 0 || matches(*argv, "dsfield") == 0) {
NEXT_ARG();
tkey->off = 1;
- res = parse_cmd(&argc, &argv, 1, TU32,RU8,sel,tkey);
+ res = parse_cmd(&argc, &argv, 1, TU32, RU8, sel, tkey);
goto done;
}
if (strcmp(*argv, "ihl") == 0) {
NEXT_ARG();
tkey->off = 0;
- res = parse_cmd(&argc, &argv, 1, TU32,0x0f,sel,tkey);
+ res = parse_cmd(&argc, &argv, 1, TU32, 0x0f, sel, tkey);
goto done;
}
if (strcmp(*argv, "protocol") == 0) {
NEXT_ARG();
tkey->off = 9;
- res = parse_cmd(&argc, &argv, 1, TU32,RU8,sel,tkey);
+ res = parse_cmd(&argc, &argv, 1, TU32, RU8, sel, tkey);
goto done;
}
/* jamal - fix this */
if (matches(*argv, "precedence") == 0) {
NEXT_ARG();
tkey->off = 1;
- res = parse_cmd(&argc, &argv, 1, TU32,RU8,sel,tkey);
+ res = parse_cmd(&argc, &argv, 1, TU32, RU8, sel, tkey);
goto done;
}
/* jamal - validate this at some point */
if (strcmp(*argv, "nofrag") == 0) {
NEXT_ARG();
tkey->off = 6;
- res = parse_cmd(&argc, &argv, 1, TU32,0x3F,sel,tkey);
+ res = parse_cmd(&argc, &argv, 1, TU32, 0x3F, sel, tkey);
goto done;
}
/* jamal - validate this at some point */
if (strcmp(*argv, "firstfrag") == 0) {
NEXT_ARG();
tkey->off = 6;
- res = parse_cmd(&argc, &argv, 1, TU32,0x1F,sel,tkey);
+ res = parse_cmd(&argc, &argv, 1, TU32, 0x1F, sel, tkey);
goto done;
}
if (strcmp(*argv, "ce") == 0) {
NEXT_ARG();
tkey->off = 6;
- res = parse_cmd(&argc, &argv, 1, TU32,0x80,sel,tkey);
+ res = parse_cmd(&argc, &argv, 1, TU32, 0x80, sel, tkey);
goto done;
}
if (strcmp(*argv, "df") == 0) {
NEXT_ARG();
tkey->off = 6;
- res = parse_cmd(&argc, &argv, 1, TU32,0x40,sel,tkey);
+ res = parse_cmd(&argc, &argv, 1, TU32, 0x40, sel, tkey);
goto done;
}
if (strcmp(*argv, "mf") == 0) {
NEXT_ARG();
tkey->off = 6;
- res = parse_cmd(&argc, &argv, 1, TU32,0x20,sel,tkey);
+ res = parse_cmd(&argc, &argv, 1, TU32, 0x20, sel, tkey);
goto done;
}
if (strcmp(*argv, "dport") == 0) {
NEXT_ARG();
tkey->off = 22;
- res = parse_cmd(&argc, &argv, 2, TU32,RU16,sel,tkey);
+ res = parse_cmd(&argc, &argv, 2, TU32, RU16, sel, tkey);
goto done;
}
if (strcmp(*argv, "sport") == 0) {
NEXT_ARG();
tkey->off = 20;
- res = parse_cmd(&argc, &argv, 2, TU32,RU16,sel,tkey);
+ res = parse_cmd(&argc, &argv, 2, TU32, RU16, sel, tkey);
goto done;
}
if (strcmp(*argv, "icmp_type") == 0) {
NEXT_ARG();
tkey->off = 20;
- res = parse_cmd(&argc, &argv, 1, TU32,RU8,sel,tkey);
+ res = parse_cmd(&argc, &argv, 1, TU32, RU8, sel, tkey);
goto done;
}
if (strcmp(*argv, "icmp_code") == 0) {
NEXT_ARG();
tkey->off = 20;
- res = parse_cmd(&argc, &argv, 1, TU32,RU8,sel,tkey);
+ res = parse_cmd(&argc, &argv, 1, TU32, RU8, sel, tkey);
goto done;
}
return -1;
- done:
+done:
*argc_p = argc;
*argv_p = argv;
return res;
}
static int
-parse_ip6(int *argc_p, char ***argv_p,struct tc_pedit_sel *sel,struct tc_pedit_key *tkey)
+parse_ip6(int *argc_p, char ***argv_p,
+ struct tc_pedit_sel *sel, struct tc_pedit_key *tkey)
{
int res = -1;
return res;
--
2.7.2
^ permalink raw reply related
* [iproute PATCH 3/4] tc: pedit: Fix raw op
From: Phil Sutter @ 2016-03-16 21:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jamal Hadi Salim, netdev
In-Reply-To: <1458164915-31802-1-git-send-email-phil@nwl.cc>
The retain value was wrong for u16 and u8 types.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
tc/m_pedit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tc/m_pedit.c b/tc/m_pedit.c
index 7de47800040bc..23bd1d5727f85 100644
--- a/tc/m_pedit.c
+++ b/tc/m_pedit.c
@@ -342,12 +342,12 @@ parse_offset(int *argc_p, char ***argv_p,struct tc_pedit_sel *sel,struct tc_pedi
}
if (matches(*argv, "u16") == 0) {
len = 2;
- retain = 0x0;
+ retain = 0xffff;
goto done;
}
if (matches(*argv, "u8") == 0) {
len = 1;
- retain = 0x0;
+ retain = 0xff;
goto done;
}
--
2.7.2
^ permalink raw reply related
* [iproute PATCH 4/4] testsuite: add a test for tc pedit action
From: Phil Sutter @ 2016-03-16 21:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jamal Hadi Salim, netdev
In-Reply-To: <1458164915-31802-1-git-send-email-phil@nwl.cc>
This is not a full test, since kernel functionality is not actually
tested. It only compares that the kernel returned values when listing
the action are what one expects them to be.
Since this test succeeded on both a little-endian and a big-endian
system, it shows that any endianness issues have been resolved in
tc/p_ip.c at least.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
testsuite/tests/tc/pedit.t | 217 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 217 insertions(+)
create mode 100755 testsuite/tests/tc/pedit.t
diff --git a/testsuite/tests/tc/pedit.t b/testsuite/tests/tc/pedit.t
new file mode 100755
index 0000000000000..e9b6c333accbe
--- /dev/null
+++ b/testsuite/tests/tc/pedit.t
@@ -0,0 +1,217 @@
+#!/bin/sh
+
+source lib/generic.sh
+
+DEV="$(rand_dev)"
+ts_ip "$0" "Add $DEV dummy interface" link add dev $DEV type dummy
+ts_ip "$0" "Enable $DEV" link set $DEV up
+ts_tc "pedit" "Add ingress qdisc" qdisc add dev $DEV ingress
+
+
+do_pedit() {
+ ts_tc "pedit" "Drop ingress qdisc" \
+ qdisc del dev $DEV ingress
+ ts_tc "pedit" "Add ingress qdisc" \
+ qdisc add dev $DEV ingress
+ ts_tc "pedit" "Add pedit action $*" \
+ filter add dev $DEV parent ffff: \
+ u32 match u32 0 0 \
+ action pedit munge $@
+ ts_tc "pedit" "Show ingress filters" \
+ filter show dev $DEV parent ffff:
+}
+
+do_pedit offset 12 u32 set 0x12345678
+test_on "key #0 at 12: val 12345678 mask 00000000"
+do_pedit offset 12 u16 set 0x1234
+test_on "key #0 at 12: val 12340000 mask 0000ffff"
+do_pedit offset 14 u16 set 0x1234
+test_on "key #0 at 12: val 00001234 mask ffff0000"
+do_pedit offset 12 u8 set 0x23
+test_on "key #0 at 12: val 23000000 mask 00ffffff"
+do_pedit offset 13 u8 set 0x23
+test_on "key #0 at 12: val 00230000 mask ff00ffff"
+do_pedit offset 14 u8 set 0x23
+test_on "key #0 at 12: val 00002300 mask ffff00ff"
+do_pedit offset 15 u8 set 0x23
+test_on "key #0 at 12: val 00000023 mask ffffff00"
+
+do_pedit offset 13 u8 invert
+test_on "key #0 at 12: val 00ff0000 mask ffffffff"
+do_pedit offset 13 u8 clear
+test_on "key #0 at 12: val 00000000 mask ff00ffff"
+do_pedit offset 13 u8 preserve
+test_on "key #0 at 12: val 00000000 mask ffffffff"
+
+# the following set of tests has been auto-generated by running this little
+# shell script:
+#
+# do_it() {
+# echo "do_pedit $@"
+# tc qd del dev veth0 ingress >/dev/null 2>&1
+# tc qd add dev veth0 ingress >/dev/null 2>&1
+# tc filter add dev veth0 parent ffff: u32 \
+# match u32 0 0 \
+# action pedit munge $@ >/dev/null 2>&1
+# tc filter show dev veth0 parent ffff: | \
+# sed -n 's/^[\t ]*\(key #0.*\)/test_on "\1"/p'
+# }
+#
+# do_it_all() { # (field, val1 [, val2, ...])
+# local field=$1
+# shift
+# for val in $@; do
+# do_it ip $field set $val
+# done
+# for i in preserve invert clear; do
+# do_it ip $field $i
+# done
+# }
+#
+# do_it_all ihl 0x04 0x40
+# do_it_all src 1.2.3.4
+# do_it_all dst 1.2.3.4
+# do_it_all tos 0x1 0x10
+# do_it_all protocol 0x23
+# do_it_all nofrag 0x23 0xf4
+# do_it_all firstfrag 0x03 0xfa
+# do_it_all ce 0x23 0x04 0xf3
+# do_it_all df 0x23 0x04 0xf3
+# do_it_all mf 0x23 0x04 0xf3
+# do_it_all dport 0x1234
+# do_it_all sport 0x1234
+# do_it_all icmp_type 0x23
+# do_it_all icmp_code 0x23
+
+do_pedit ip ihl set 0x04
+test_on "key #0 at 0: val 04000000 mask f0ffffff"
+do_pedit ip ihl set 0x40
+test_on "key #0 at 0: val 00000000 mask f0ffffff"
+do_pedit ip ihl preserve
+test_on "key #0 at 0: val 00000000 mask ffffffff"
+do_pedit ip ihl invert
+test_on "key #0 at 0: val 0f000000 mask ffffffff"
+do_pedit ip ihl clear
+test_on "key #0 at 0: val 00000000 mask f0ffffff"
+do_pedit ip src set 1.2.3.4
+test_on "key #0 at 12: val 01020304 mask 00000000"
+do_pedit ip src preserve
+test_on "key #0 at 12: val 00000000 mask ffffffff"
+do_pedit ip src invert
+test_on "key #0 at 12: val ffffffff mask ffffffff"
+do_pedit ip src clear
+test_on "key #0 at 12: val 00000000 mask 00000000"
+do_pedit ip dst set 1.2.3.4
+test_on "key #0 at 16: val 01020304 mask 00000000"
+do_pedit ip dst preserve
+test_on "key #0 at 16: val 00000000 mask ffffffff"
+do_pedit ip dst invert
+test_on "key #0 at 16: val ffffffff mask ffffffff"
+do_pedit ip dst clear
+test_on "key #0 at 16: val 00000000 mask 00000000"
+do_pedit ip tos set 0x1
+test_on "key #0 at 0: val 00010000 mask ff00ffff"
+do_pedit ip tos set 0x10
+test_on "key #0 at 0: val 00100000 mask ff00ffff"
+do_pedit ip tos preserve
+test_on "key #0 at 0: val 00000000 mask ffffffff"
+do_pedit ip tos invert
+test_on "key #0 at 0: val 00ff0000 mask ffffffff"
+do_pedit ip tos clear
+test_on "key #0 at 0: val 00000000 mask ff00ffff"
+do_pedit ip protocol set 0x23
+test_on "key #0 at 8: val 00230000 mask ff00ffff"
+do_pedit ip protocol preserve
+test_on "key #0 at 8: val 00000000 mask ffffffff"
+do_pedit ip protocol invert
+test_on "key #0 at 8: val 00ff0000 mask ffffffff"
+do_pedit ip protocol clear
+test_on "key #0 at 8: val 00000000 mask ff00ffff"
+do_pedit ip nofrag set 0x23
+test_on "key #0 at 4: val 00002300 mask ffffc0ff"
+do_pedit ip nofrag set 0xf4
+test_on "key #0 at 4: val 00003400 mask ffffc0ff"
+do_pedit ip nofrag preserve
+test_on "key #0 at 4: val 00000000 mask ffffffff"
+do_pedit ip nofrag invert
+test_on "key #0 at 4: val 00003f00 mask ffffffff"
+do_pedit ip nofrag clear
+test_on "key #0 at 4: val 00000000 mask ffffc0ff"
+do_pedit ip firstfrag set 0x03
+test_on "key #0 at 4: val 00000300 mask ffffe0ff"
+do_pedit ip firstfrag set 0xfa
+test_on "key #0 at 4: val 00001a00 mask ffffe0ff"
+do_pedit ip firstfrag preserve
+test_on "key #0 at 4: val 00000000 mask ffffffff"
+do_pedit ip firstfrag invert
+test_on "key #0 at 4: val 00001f00 mask ffffffff"
+do_pedit ip firstfrag clear
+test_on "key #0 at 4: val 00000000 mask ffffe0ff"
+do_pedit ip ce set 0x23
+test_on "key #0 at 4: val 00000000 mask ffff7fff"
+do_pedit ip ce set 0x04
+test_on "key #0 at 4: val 00000000 mask ffff7fff"
+do_pedit ip ce set 0xf3
+test_on "key #0 at 4: val 00008000 mask ffff7fff"
+do_pedit ip ce preserve
+test_on "key #0 at 4: val 00000000 mask ffffffff"
+do_pedit ip ce invert
+test_on "key #0 at 4: val 00008000 mask ffffffff"
+do_pedit ip ce clear
+test_on "key #0 at 4: val 00000000 mask ffff7fff"
+do_pedit ip df set 0x23
+test_on "key #0 at 4: val 00000000 mask ffffbfff"
+do_pedit ip df set 0x04
+test_on "key #0 at 4: val 00000000 mask ffffbfff"
+do_pedit ip df set 0xf3
+test_on "key #0 at 4: val 00004000 mask ffffbfff"
+do_pedit ip df preserve
+test_on "key #0 at 4: val 00000000 mask ffffffff"
+do_pedit ip df invert
+test_on "key #0 at 4: val 00004000 mask ffffffff"
+do_pedit ip df clear
+test_on "key #0 at 4: val 00000000 mask ffffbfff"
+do_pedit ip mf set 0x23
+test_on "key #0 at 4: val 00002000 mask ffffdfff"
+do_pedit ip mf set 0x04
+test_on "key #0 at 4: val 00000000 mask ffffdfff"
+do_pedit ip mf set 0xf3
+test_on "key #0 at 4: val 00002000 mask ffffdfff"
+do_pedit ip mf preserve
+test_on "key #0 at 4: val 00000000 mask ffffffff"
+do_pedit ip mf invert
+test_on "key #0 at 4: val 00002000 mask ffffffff"
+do_pedit ip mf clear
+test_on "key #0 at 4: val 00000000 mask ffffdfff"
+do_pedit ip dport set 0x1234
+test_on "key #0 at 20: val 00001234 mask ffff0000"
+do_pedit ip dport preserve
+test_on "key #0 at 20: val 00000000 mask ffffffff"
+do_pedit ip dport invert
+test_on "key #0 at 20: val 0000ffff mask ffffffff"
+do_pedit ip dport clear
+test_on "key #0 at 20: val 00000000 mask ffff0000"
+do_pedit ip sport set 0x1234
+test_on "key #0 at 20: val 12340000 mask 0000ffff"
+do_pedit ip sport preserve
+test_on "key #0 at 20: val 00000000 mask ffffffff"
+do_pedit ip sport invert
+test_on "key #0 at 20: val ffff0000 mask ffffffff"
+do_pedit ip sport clear
+test_on "key #0 at 20: val 00000000 mask 0000ffff"
+do_pedit ip icmp_type set 0x23
+test_on "key #0 at 20: val 23000000 mask 00ffffff"
+do_pedit ip icmp_type preserve
+test_on "key #0 at 20: val 00000000 mask ffffffff"
+do_pedit ip icmp_type invert
+test_on "key #0 at 20: val ff000000 mask ffffffff"
+do_pedit ip icmp_type clear
+test_on "key #0 at 20: val 00000000 mask 00ffffff"
+do_pedit ip icmp_code set 0x23
+test_on "key #0 at 20: val 23000000 mask 00ffffff"
+do_pedit ip icmp_code preserve
+test_on "key #0 at 20: val 00000000 mask ffffffff"
+do_pedit ip icmp_code invert
+test_on "key #0 at 20: val ff000000 mask ffffffff"
+do_pedit ip icmp_code clear
+test_on "key #0 at 20: val 00000000 mask 00ffffff"
--
2.7.2
^ permalink raw reply related
* [iproute PATCH 5/8] man: tc-police.8: Emphasize on the two rate control mechanisms
From: Phil Sutter @ 2016-03-16 21:56 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jamal Hadi Salim, netdev
In-Reply-To: <1458165384-900-1-git-send-email-phil@nwl.cc>
As Jamal pointed out, there are two different approaches to bandwidth
measurement. Try to make this clear by separating them in synopsis and
also documenting the way to fine-tune avrate.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
man/man8/tc-police.8 | 29 +++++++++++++++++++++++++----
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/man/man8/tc-police.8 b/man/man8/tc-police.8
index 2b1537ec52875..5c5a632335dc9 100644
--- a/man/man8/tc-police.8
+++ b/man/man8/tc-police.8
@@ -12,13 +12,21 @@ police - policing action
.IR BYTES [\fB/ BYTES "] ] ["
.BI peakrate " RATE"
] [
-.BI avrate " RATE"
-] [
.BI overhead " BYTES"
] [
.BI linklayer " TYPE"
] [
-.BI conform-exceed " EXCEEDACT\fR[\fB/\fIEXCEEDACT\fR]"
+.IR CONTROL " ]"
+
+.ti -8
+.BR tc " ... " filter " ... [ " estimator
+.IR "SAMPLE AVERAGE " ]
+.BR "action police avrate"
+.IR RATE " [ " CONTROL " ]"
+
+.ti -8
+.IR CONTROL " :="
+.BI conform-exceed " EXCEEDACT\fR[\fB/\fIEXCEEDACT"
.ti -8
.IR EXCEEDACT " := { "
@@ -27,7 +35,14 @@ police - policing action
The
.B police
action allows to limit bandwidth of traffic matched by the filter it is
-attached to.
+attached to. Basically there are two different algorithms available to measure
+the packet rate: The first one uses an internal dual token bucket and is
+configured using the
+.BR rate ", " burst ", " mtu ", " peakrate ", " overhead " and " linklayer
+parameters. The second one uses an in-kernel sampling mechanism. It can be
+fine-tuned using the
+.B estimator
+filter parameter.
.SH OPTIONS
.TP
.BI rate " RATE"
@@ -73,6 +88,12 @@ cell sizes, for
.B ethernet
no action is taken.
.TP
+.BI estimator " SAMPLE AVERAGE"
+Fine-tune the in-kernel packet rate estimator.
+.IR SAMPLE " and " AVERAGE
+are time values and control the frequency in which samples are taken and over
+what timespan an average is built.
+.TP
.BI conform-exceed " EXCEEDACT\fR[\fB/\fIEXCEEDACT\fR]"
Define how to handle packets which exceed (and, if the second
.I EXCEEDACT
--
2.7.2
^ permalink raw reply related
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