* Re: [PATCH net-next] net/sched: cls_flower: Support matching on SCTP ports
From: Jiri Pirko @ 2016-11-03 12:31 UTC (permalink / raw)
To: Simon Horman; +Cc: David Miller, netdev, Jiri Pirko
In-Reply-To: <1478175862-28642-1-git-send-email-simon.horman@netronome.com>
Thu, Nov 03, 2016 at 01:24:21PM CET, simon.horman@netronome.com wrote:
>Support matching on SCTP ports in the same way that matching
>on TCP and UDP ports is already supported.
>
>Example usage:
>
>tc qdisc add dev eth0 ingress
>
>tc filter add dev eth0 protocol ip parent ffff: \
> flower indev eth0 ip_proto sctp dst_port 80 \
> action drop
>
>Signed-off-by: Simon Horman <simon.horman@netronome.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH] net/sched: cls_flower: Support matching on SCTP ports
From: Simon Horman @ 2016-11-03 12:28 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Jiri Pirko
In-Reply-To: <1478175862-28642-2-git-send-email-simon.horman@netronome.com>
On Thu, Nov 03, 2016 at 01:24:22PM +0100, Simon Horman wrote:
> Support matching on SCTP ports in the same way that matching
> on TCP and UDP ports is already supported.
Sorry for this duplicate, I was having network troubles and it
seems to have suck out somehow.
^ permalink raw reply
* [PATCH iproute2 2/2] tc: flower: Support matching on SCTP ports
From: Simon Horman @ 2016-11-03 12:26 UTC (permalink / raw)
To: David Miller, Stephen Hemminger; +Cc: netdev, Simon Horman
In-Reply-To: <1478176001-29174-1-git-send-email-simon.horman@netronome.com>
Support matching on SCTP ports in the same way that matching
on TCP and UDP ports is already supported.
Example usage:
tc qdisc add dev eth0 ingress
tc filter add dev eth0 protocol ip parent ffff: \
flower indev eth0 ip_proto sctp dst_port 80 \
action drop
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
tc/f_flower.c | 65 ++++++++++++++++++++++++++++-------------------------------
1 file changed, 31 insertions(+), 34 deletions(-)
diff --git a/tc/f_flower.c b/tc/f_flower.c
index 2d31d1aa832d..72fe42bc19be 100644
--- a/tc/f_flower.c
+++ b/tc/f_flower.c
@@ -96,6 +96,8 @@ static int flower_parse_ip_proto(char *str, __be16 eth_type, int type,
ip_proto = IPPROTO_TCP;
} else if (matches(str, "udp") == 0) {
ip_proto = IPPROTO_UDP;
+ } else if (matches(str, "sctp") == 0) {
+ ip_proto = IPPROTO_SCTP;
} else {
ret = get_u8(&ip_proto, str, 16);
if (ret)
@@ -156,21 +158,33 @@ static int flower_parse_ip_addr(char *str, __be16 eth_type,
return 0;
}
-static int flower_parse_port(char *str, __u8 ip_port,
- int tcp_type, int udp_type, struct nlmsghdr *n)
+static int flower_port_attr_type(__u8 ip_port, bool is_src)
{
- int ret;
- int type;
- __be16 port;
-
if (ip_port == IPPROTO_TCP) {
- type = tcp_type;
+ return is_src ? TCA_FLOWER_KEY_TCP_SRC :
+ TCA_FLOWER_KEY_TCP_DST;
} else if (ip_port == IPPROTO_UDP) {
- type = udp_type;
+ return is_src ? TCA_FLOWER_KEY_UDP_SRC :
+ TCA_FLOWER_KEY_UDP_DST;
+ } else if (ip_port == IPPROTO_SCTP) {
+ return is_src ? TCA_FLOWER_KEY_SCTP_SRC :
+ TCA_FLOWER_KEY_SCTP_DST;
} else {
fprintf(stderr, "Illegal \"ip_proto\" for port\n");
return -1;
}
+}
+
+static int flower_parse_port(char *str, __u8 ip_port, bool is_src,
+ struct nlmsghdr *n)
+{
+ int ret;
+ int type;
+ __be16 port;
+
+ type = flower_port_attr_type(ip_port, is_src);
+ if (type < 0)
+ return -1;
ret = get_be16(&port, str, 10);
if (ret)
@@ -323,18 +337,14 @@ static int flower_parse_opt(struct filter_util *qu, char *handle,
}
} else if (matches(*argv, "dst_port") == 0) {
NEXT_ARG();
- ret = flower_parse_port(*argv, ip_proto,
- TCA_FLOWER_KEY_TCP_DST,
- TCA_FLOWER_KEY_UDP_DST, n);
+ ret = flower_parse_port(*argv, ip_proto, false, n);
if (ret < 0) {
fprintf(stderr, "Illegal \"dst_port\"\n");
return -1;
}
} else if (matches(*argv, "src_port") == 0) {
NEXT_ARG();
- ret = flower_parse_port(*argv, ip_proto,
- TCA_FLOWER_KEY_TCP_SRC,
- TCA_FLOWER_KEY_UDP_SRC, n);
+ ret = flower_parse_port(*argv, ip_proto, true, n);
if (ret < 0) {
fprintf(stderr, "Illegal \"src_port\"\n");
return -1;
@@ -450,6 +460,8 @@ static void flower_print_ip_proto(FILE *f, __u8 *p_ip_proto,
fprintf(f, "tcp");
else if (ip_proto == IPPROTO_UDP)
fprintf(f, "udp");
+ else if (ip_proto == IPPROTO_SCTP)
+ fprintf(f, "sctp");
else
fprintf(f, "%02x", ip_proto);
*p_ip_proto = ip_proto;
@@ -492,20 +504,8 @@ static void flower_print_ip_addr(FILE *f, char *name, __be16 eth_type,
fprintf(f, "/%d", bits);
}
-static void flower_print_port(FILE *f, char *name, __u8 ip_proto,
- struct rtattr *tcp_attr,
- struct rtattr *udp_attr)
+static void flower_print_port(FILE *f, char *name, struct rtattr *attr)
{
- struct rtattr *attr;
-
- if (ip_proto == IPPROTO_TCP)
- attr = tcp_attr;
- else if (ip_proto == IPPROTO_UDP)
- attr = udp_attr;
- else
- return;
- if (!attr)
- return;
fprintf(f, "\n %s %d", name, ntohs(rta_getattr_u16(attr)));
}
@@ -569,13 +569,10 @@ static int flower_print_opt(struct filter_util *qu, FILE *f,
tb[TCA_FLOWER_KEY_IPV6_SRC],
tb[TCA_FLOWER_KEY_IPV6_SRC_MASK]);
- flower_print_port(f, "dst_port", ip_proto,
- tb[TCA_FLOWER_KEY_TCP_DST],
- tb[TCA_FLOWER_KEY_UDP_DST]);
-
- flower_print_port(f, "src_port", ip_proto,
- tb[TCA_FLOWER_KEY_TCP_SRC],
- tb[TCA_FLOWER_KEY_UDP_SRC]);
+ flower_print_port(f, "dst_port",
+ tb[flower_port_attr_type(ip_proto, false)]);
+ flower_print_port(f, "src_port",
+ tb[flower_port_attr_type(ip_proto, true)]);
if (tb[TCA_FLOWER_FLAGS]) {
__u32 flags = rta_getattr_u32(tb[TCA_FLOWER_FLAGS]);
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH iproute2 1/2] tc: update headers for TCA_FLOWER_KEY_SCTP_*
From: Simon Horman @ 2016-11-03 12:26 UTC (permalink / raw)
To: David Miller, Stephen Hemminger; +Cc: netdev, Simon Horman
In-Reply-To: <1478176001-29174-1-git-send-email-simon.horman@netronome.com>
These are proposed changes for net-next.
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
include/linux/pkt_cls.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/linux/pkt_cls.h b/include/linux/pkt_cls.h
index b47ed3af22b6..974155a67d2d 100644
--- a/include/linux/pkt_cls.h
+++ b/include/linux/pkt_cls.h
@@ -393,6 +393,11 @@ enum {
TCA_FLOWER_KEY_TCP_DST_MASK, /* be16 */
TCA_FLOWER_KEY_UDP_SRC_MASK, /* be16 */
TCA_FLOWER_KEY_UDP_DST_MASK, /* be16 */
+ TCA_FLOWER_KEY_SCTP_SRC_MASK, /* be16 */
+ TCA_FLOWER_KEY_SCTP_DST_MASK, /* be16 */
+
+ TCA_FLOWER_KEY_SCTP_SRC, /* be16 */
+ TCA_FLOWER_KEY_SCTP_DST, /* be16 */
__TCA_FLOWER_MAX,
};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH iproute2 0/2] tc: flower: Support matching on SCTP ports
From: Simon Horman @ 2016-11-03 12:26 UTC (permalink / raw)
To: David Miller, Stephen Hemminger; +Cc: netdev, Simon Horman
Hi,
this short series adds support for matching on SCTP ports in the same way
that matching on TCP and UDP ports is already supported. It corresponds to
a net-next patch to add the same support to the kernel.
Example usage:
tc qdisc add dev eth0 ingress
tc filter add dev eth0 protocol ip parent ffff: \
flower indev eth0 ip_proto sctp dst_port 80 \
action drop
Simon Horman (2):
tc: update headers for TCA_FLOWER_KEY_SCTP_*
tc: flower: Support matching on SCTP ports
include/linux/pkt_cls.h | 5 ++++
tc/f_flower.c | 65 +++++++++++++++++++++++--------------------------
2 files changed, 36 insertions(+), 34 deletions(-)
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply
* [PATCH] net/sched: cls_flower: Support matching on SCTP ports
From: Simon Horman @ 2016-11-03 12:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Jiri Pirko, Simon Horman
In-Reply-To: <1478175862-28642-1-git-send-email-simon.horman@netronome.com>
Support matching on SCTP ports in the same way that matching
on TCP and UDP ports is already supported.
Example usage:
tc qdisc add dev eth0 ingress
tc filter add dev eth0 protocol ip parent ffff: \
flower indev eth0 ip_proto sctp dst_port 80 \
action drop
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
include/uapi/linux/pkt_cls.h | 5 +++++
net/sched/cls_flower.c | 19 +++++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index 8fd715f806a2..eb94781757ee 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -447,6 +447,11 @@ enum {
TCA_FLOWER_KEY_TCP_DST_MASK, /* be16 */
TCA_FLOWER_KEY_UDP_SRC_MASK, /* be16 */
TCA_FLOWER_KEY_UDP_DST_MASK, /* be16 */
+ TCA_FLOWER_KEY_SCTP_SRC_MASK, /* be16 */
+ TCA_FLOWER_KEY_SCTP_DST_MASK, /* be16 */
+
+ TCA_FLOWER_KEY_SCTP_SRC, /* be16 */
+ TCA_FLOWER_KEY_SCTP_DST, /* be16 */
__TCA_FLOWER_MAX,
};
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index a8fb1ca03b3e..db4cd882a989 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -344,6 +344,10 @@ static const struct nla_policy fl_policy[TCA_FLOWER_MAX + 1] = {
[TCA_FLOWER_KEY_TCP_DST_MASK] = { .type = NLA_U16 },
[TCA_FLOWER_KEY_UDP_SRC_MASK] = { .type = NLA_U16 },
[TCA_FLOWER_KEY_UDP_DST_MASK] = { .type = NLA_U16 },
+ [TCA_FLOWER_KEY_SCTP_SRC_MASK] = { .type = NLA_U16 },
+ [TCA_FLOWER_KEY_SCTP_DST_MASK] = { .type = NLA_U16 },
+ [TCA_FLOWER_KEY_SCTP_SRC] = { .type = NLA_U16 },
+ [TCA_FLOWER_KEY_SCTP_DST] = { .type = NLA_U16 },
};
static void fl_set_key_val(struct nlattr **tb,
@@ -453,6 +457,13 @@ static int fl_set_key(struct net *net, struct nlattr **tb,
fl_set_key_val(tb, &key->tp.dst, TCA_FLOWER_KEY_UDP_DST,
&mask->tp.dst, TCA_FLOWER_KEY_UDP_DST_MASK,
sizeof(key->tp.dst));
+ } else if (key->basic.ip_proto == IPPROTO_SCTP) {
+ fl_set_key_val(tb, &key->tp.src, TCA_FLOWER_KEY_SCTP_SRC,
+ &mask->tp.src, TCA_FLOWER_KEY_SCTP_SRC_MASK,
+ sizeof(key->tp.src));
+ fl_set_key_val(tb, &key->tp.dst, TCA_FLOWER_KEY_SCTP_DST,
+ &mask->tp.dst, TCA_FLOWER_KEY_SCTP_DST_MASK,
+ sizeof(key->tp.dst));
}
if (tb[TCA_FLOWER_KEY_ENC_IPV4_SRC] ||
@@ -897,6 +908,14 @@ static int fl_dump(struct net *net, struct tcf_proto *tp, unsigned long fh,
&mask->tp.dst, TCA_FLOWER_KEY_UDP_DST_MASK,
sizeof(key->tp.dst))))
goto nla_put_failure;
+ else if (key->basic.ip_proto == IPPROTO_SCTP &&
+ (fl_dump_key_val(skb, &key->tp.src, TCA_FLOWER_KEY_SCTP_SRC,
+ &mask->tp.src, TCA_FLOWER_KEY_SCTP_SRC_MASK,
+ sizeof(key->tp.src)) ||
+ fl_dump_key_val(skb, &key->tp.dst, TCA_FLOWER_KEY_SCTP_DST,
+ &mask->tp.dst, TCA_FLOWER_KEY_SCTP_DST_MASK,
+ sizeof(key->tp.dst))))
+ goto nla_put_failure;
if (key->enc_control.addr_type == FLOW_DISSECTOR_KEY_IPV4_ADDRS &&
(fl_dump_key_val(skb, &key->enc_ipv4.src,
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH net-next] net/sched: cls_flower: Support matching on SCTP ports
From: Simon Horman @ 2016-11-03 12:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Jiri Pirko, Simon Horman
Support matching on SCTP ports in the same way that matching
on TCP and UDP ports is already supported.
Example usage:
tc qdisc add dev eth0 ingress
tc filter add dev eth0 protocol ip parent ffff: \
flower indev eth0 ip_proto sctp dst_port 80 \
action drop
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
include/uapi/linux/pkt_cls.h | 5 +++++
net/sched/cls_flower.c | 19 +++++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index 8fd715f806a2..eb94781757ee 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -447,6 +447,11 @@ enum {
TCA_FLOWER_KEY_TCP_DST_MASK, /* be16 */
TCA_FLOWER_KEY_UDP_SRC_MASK, /* be16 */
TCA_FLOWER_KEY_UDP_DST_MASK, /* be16 */
+ TCA_FLOWER_KEY_SCTP_SRC_MASK, /* be16 */
+ TCA_FLOWER_KEY_SCTP_DST_MASK, /* be16 */
+
+ TCA_FLOWER_KEY_SCTP_SRC, /* be16 */
+ TCA_FLOWER_KEY_SCTP_DST, /* be16 */
__TCA_FLOWER_MAX,
};
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index a8fb1ca03b3e..db4cd882a989 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -344,6 +344,10 @@ static const struct nla_policy fl_policy[TCA_FLOWER_MAX + 1] = {
[TCA_FLOWER_KEY_TCP_DST_MASK] = { .type = NLA_U16 },
[TCA_FLOWER_KEY_UDP_SRC_MASK] = { .type = NLA_U16 },
[TCA_FLOWER_KEY_UDP_DST_MASK] = { .type = NLA_U16 },
+ [TCA_FLOWER_KEY_SCTP_SRC_MASK] = { .type = NLA_U16 },
+ [TCA_FLOWER_KEY_SCTP_DST_MASK] = { .type = NLA_U16 },
+ [TCA_FLOWER_KEY_SCTP_SRC] = { .type = NLA_U16 },
+ [TCA_FLOWER_KEY_SCTP_DST] = { .type = NLA_U16 },
};
static void fl_set_key_val(struct nlattr **tb,
@@ -453,6 +457,13 @@ static int fl_set_key(struct net *net, struct nlattr **tb,
fl_set_key_val(tb, &key->tp.dst, TCA_FLOWER_KEY_UDP_DST,
&mask->tp.dst, TCA_FLOWER_KEY_UDP_DST_MASK,
sizeof(key->tp.dst));
+ } else if (key->basic.ip_proto == IPPROTO_SCTP) {
+ fl_set_key_val(tb, &key->tp.src, TCA_FLOWER_KEY_SCTP_SRC,
+ &mask->tp.src, TCA_FLOWER_KEY_SCTP_SRC_MASK,
+ sizeof(key->tp.src));
+ fl_set_key_val(tb, &key->tp.dst, TCA_FLOWER_KEY_SCTP_DST,
+ &mask->tp.dst, TCA_FLOWER_KEY_SCTP_DST_MASK,
+ sizeof(key->tp.dst));
}
if (tb[TCA_FLOWER_KEY_ENC_IPV4_SRC] ||
@@ -897,6 +908,14 @@ static int fl_dump(struct net *net, struct tcf_proto *tp, unsigned long fh,
&mask->tp.dst, TCA_FLOWER_KEY_UDP_DST_MASK,
sizeof(key->tp.dst))))
goto nla_put_failure;
+ else if (key->basic.ip_proto == IPPROTO_SCTP &&
+ (fl_dump_key_val(skb, &key->tp.src, TCA_FLOWER_KEY_SCTP_SRC,
+ &mask->tp.src, TCA_FLOWER_KEY_SCTP_SRC_MASK,
+ sizeof(key->tp.src)) ||
+ fl_dump_key_val(skb, &key->tp.dst, TCA_FLOWER_KEY_SCTP_DST,
+ &mask->tp.dst, TCA_FLOWER_KEY_SCTP_DST_MASK,
+ sizeof(key->tp.dst))))
+ goto nla_put_failure;
if (key->enc_control.addr_type == FLOW_DISSECTOR_KEY_IPV4_ADDRS &&
(fl_dump_key_val(skb, &key->enc_ipv4.src,
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* Re: [PATCH net] ehea: fix operation state report
From: Douglas Miller @ 2016-11-03 12:19 UTC (permalink / raw)
To: Guilherme G. Piccoli, netdev; +Cc: zhou
In-Reply-To: <1478168180-18371-1-git-send-email-gpiccoli@linux.vnet.ibm.com>
On 11/03/2016 05:16 AM, Guilherme G. Piccoli wrote:
> Currently the ehea driver is missing a call to netif_carrier_off()
> before the interface bring-up; this is necessary in order to
> initialize the __LINK_STATE_NOCARRIER bit in the net_device state
> field. Otherwise, we observe state UNKNOWN on "ip address" command
> output.
>
> This patch adds a call to netif_carrier_off() on ehea's net device
> open callback.
>
> Reported-by: Xiong Zhou <zhou@redhat.com>
> Reference-ID: IBM bz #137702, Red Hat bz #1089134
> Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
> ---
> drivers/net/ethernet/ibm/ehea/ehea_main.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/ibm/ehea/ehea_main.c b/drivers/net/ethernet/ibm/ehea/ehea_main.c
> index 54efa9a..bd719e2 100644
> --- a/drivers/net/ethernet/ibm/ehea/ehea_main.c
> +++ b/drivers/net/ethernet/ibm/ehea/ehea_main.c
> @@ -2446,6 +2446,8 @@ static int ehea_open(struct net_device *dev)
>
> netif_info(port, ifup, dev, "enabling port\n");
>
> + netif_carrier_off(dev);
> +
> ret = ehea_up(dev);
> if (!ret) {
> port_napi_enable(port);
Signed-off-by: Douglas Miller <dougmill@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH iproute2] tc: flower: Fix usage message
From: Simon Horman @ 2016-11-03 12:11 UTC (permalink / raw)
To: Paul Blakey; +Cc: netdev, Or Gerlitz
In-Reply-To: <1478099398-21639-1-git-send-email-paulb@mellanox.com>
On Wed, Nov 02, 2016 at 05:09:58PM +0200, Paul Blakey wrote:
> Remove left over usage from removal of eth_type argument.
>
> Fixes: 488b41d020fb ('tc: flower no need to specify the ethertype')
> Signed-off-by: Paul Blakey <paulb@mellanox.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
^ permalink raw reply
* Re: [PATCH net] r8152: Fix broken RX checksums.
From: Mark Lord @ 2016-11-03 11:43 UTC (permalink / raw)
To: Hayes Wang, David Miller
Cc: nic_swsd, netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB20104878A@RTITMBSV03.realtek.com.tw>
On 16-11-03 04:56 AM, Hayes Wang wrote:
> Mark Lord [mailto:mlord@pobox.com]
>> Sent: Thursday, November 03, 2016 2:30 AM
>> To: Hayes Wang; David Miller
> [...]
>> I have poked at it some more, and thus far it appears that it is
>> only necessary to disable TCP rx checksums. The system doesn't crash
>> when only IP/UDP checksums are enabled, but does when TCP checksums are on.
>>
>> This happens regardless of whether RX_AGG is disabled or enabled,
>> and increasing/decreasing the number of RX URBs (RTL8152_MAX_RX)
>> doesn't seem to affect it.
>
> I test Raspberry Pi v1, but I couldn't boot with NFSROOT through
> both onboard nic and RTL8152. I get following error.
>
> VFS: Unable to mount root fs via NFS, trying floppy.
> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
>
> However, if I start the system without NFSROOT, I could mount the nfs fs.
> Any idea?
Rather than getting caught up in all of that,
you could then just chroot to the mounted nfs fs
at that point, and continue on from there.
Eg. chroot /mnt/nfsxxx /bin/sh
Running from NFS is probably not necessary though.
Instead, perhaps just run md5sum on every file on the nfs fs
from the Raspberry Pi, and then repeat the md5sum's on the server,
and compare the results for errors.
The system I am using the dongle with is a custom embedded board,
but I think the important thing is that it has a slow-ish CPU,
which means it is more prone to having the on-chip RX FIFO overflow.
It is also big-endian rather than little-endian, though that seems
to be correctly handled already in the device driver.
I will try the md5sum test on an x86 box for comparison.
Cheers
--
Mark Lord
^ permalink raw reply
* Your trust
From: admin @ 2016-11-02 15:49 UTC (permalink / raw)
Good day,
My name is Yi Tan, I work with the finance house here in Hong Kong. I
found your address through my countries international Web directory. I
have a business of mutual benefit involve transfer of fund for investment
for both of us.
If you are interested please contact me on my
email(yitanelectronhk@gmail.com)
Regards,
Yi Tan
^ permalink raw reply
* [PATCH net] ehea: fix operation state report
From: Guilherme G. Piccoli @ 2016-11-03 10:16 UTC (permalink / raw)
To: netdev; +Cc: dougmill, zhou, Guilherme G. Piccoli
Currently the ehea driver is missing a call to netif_carrier_off()
before the interface bring-up; this is necessary in order to
initialize the __LINK_STATE_NOCARRIER bit in the net_device state
field. Otherwise, we observe state UNKNOWN on "ip address" command
output.
This patch adds a call to netif_carrier_off() on ehea's net device
open callback.
Reported-by: Xiong Zhou <zhou@redhat.com>
Reference-ID: IBM bz #137702, Red Hat bz #1089134
Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
---
drivers/net/ethernet/ibm/ehea/ehea_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/ibm/ehea/ehea_main.c b/drivers/net/ethernet/ibm/ehea/ehea_main.c
index 54efa9a..bd719e2 100644
--- a/drivers/net/ethernet/ibm/ehea/ehea_main.c
+++ b/drivers/net/ethernet/ibm/ehea/ehea_main.c
@@ -2446,6 +2446,8 @@ static int ehea_open(struct net_device *dev)
netif_info(port, ifup, dev, "enabling port\n");
+ netif_carrier_off(dev);
+
ret = ehea_up(dev);
if (!ret) {
port_napi_enable(port);
--
2.1.0
^ permalink raw reply related
* Re: [PATCH net v3] ipv4: allow local fragmentation in ip_finish_output_gso()
From: Hannes Frederic Sowa @ 2016-11-03 9:44 UTC (permalink / raw)
To: Shmulik Ladkani, Lance Richardson; +Cc: netdev, fw, jtluka
In-Reply-To: <20161103094239.13ac8ac2@pixies>
On 03.11.2016 08:42, Shmulik Ladkani wrote:
> On Wed, 2 Nov 2016 16:36:17 -0400
> Lance Richardson <lrichard@redhat.com> wrote:
>
>> - /* common case: fragmentation of segments is not allowed,
>> - * or seglen is <= mtu
>> + /* common case: seglen is <= mtu
>> */
>> - if (((IPCB(skb)->flags & IPSKB_FRAG_SEGS) == 0) ||
>> - skb_gso_validate_mtu(skb, mtu))
>> + if (skb_gso_validate_mtu(skb, mtu))
>> return ip_finish_output2(net, sk, skb);
>
> OK.
> Resembles https://patchwork.ozlabs.org/patch/644724/ ;)
>
>> - if (skb_iif && !(df & htons(IP_DF))) {
>> - /* Arrived from an ingress interface, got encapsulated, with
>> - * fragmentation of encapulating frames allowed.
>> - * If skb is gso, the resulting encapsulated network segments
>> - * may exceed dst mtu.
>> - * Allow IP Fragmentation of segments.
>> - */
>> - IPCB(skb)->flags |= IPSKB_FRAG_SEGS;
>> - }
>
> The only potential issue I see removing this, is that the KNOWLEDGE of
> the forwarding/tunnel-bridging usecases (that require a
> skb_gso_validate_mtu check) is lost.
>
> Meaning, if one decides (as claimed in the past) that locally generated
> traffic must NOT go through fragmentation validation, then no one
> remembers those other valid usecases (which are very specific and not
> trivial to imagine) that MUST go through it; Therefore it can easily get
> broken.
I agree but I think the git changelog reassembles the changes in this
area in good enough detail and it can be added if there is need for that
currently I don't see a reason why to leave this code there.
I am a bit sad to remove this condition, but the alternative, to
generate oversized frames, is absolutely not acceptable. :/
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH net v3] ipv4: allow local fragmentation in ip_finish_output_gso()
From: Hannes Frederic Sowa @ 2016-11-03 9:42 UTC (permalink / raw)
To: Lance Richardson, netdev, fw, jtluka
In-Reply-To: <1478118977-19608-1-git-send-email-lrichard@redhat.com>
On 02.11.2016 21:36, Lance Richardson wrote:
> Some configurations (e.g. geneve interface with default
> MTU of 1500 over an ethernet interface with 1500 MTU) result
> in the transmission of packets that exceed the configured MTU.
> While this should be considered to be a "bad" configuration,
> it is still allowed and should not result in the sending
> of packets that exceed the configured MTU.
>
> Fix by dropping the assumption in ip_finish_output_gso() that
> locally originated gso packets will never need fragmentation.
> Basic testing using iperf (observing CPU usage and bandwidth)
> have shown no measurable performance impact for traffic not
> requiring fragmentation.
>
> Fixes: c7ba65d7b649 ("net: ip: push gso skb forwarding handling down the stack")
> Reported-by: Jan Tluka <jtluka@redhat.com>
> Signed-off-by: Lance Richardson <lrichard@redhat.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Thanks Florian for remembering that we can remove IPSKB_FRAG_SEGS now
again. :)
^ permalink raw reply
* [PATCH] igmp: Make igmp group member RFC 3376 compliant
From: Michal Tesar @ 2016-11-03 9:38 UTC (permalink / raw)
To: davem, kuznet, jmorris, kaber, netdev
5.2. Action on Reception of a Query
When a system receives a Query, it does not respond immediately.
Instead, it delays its response by a random amount of time, bounded
by the Max Resp Time value derived from the Max Resp Code in the
received Query message. A system may receive a variety of Queries on
different interfaces and of different kinds (e.g., General Queries,
Group-Specific Queries, and Group-and-Source-Specific Queries), each
of which may require its own delayed response.
Before scheduling a response to a Query, the system must first
consider previously scheduled pending responses and in many cases
schedule a combined response. Therefore, the system must be able to
maintain the following state:
o A timer per interface for scheduling responses to General Queries.
o A per-group and interface timer for scheduling responses to Group-
Specific and Group-and-Source-Specific Queries.
o A per-group and interface list of sources to be reported in the
response to a Group-and-Source-Specific Query.
When a new Query with the Router-Alert option arrives on an
interface, provided the system has state to report, a delay for a
response is randomly selected in the range (0, [Max Resp Time]) where
Max Resp Time is derived from Max Resp Code in the received Query
message. The following rules are then used to determine if a Report
needs to be scheduled and the type of Report to schedule. The rules
are considered in order and only the first matching rule is applied.
1. If there is a pending response to a previous General Query
scheduled sooner than the selected delay, no additional response
needs to be scheduled.
2. If the received Query is a General Query, the interface timer is
used to schedule a response to the General Query after the
selected delay. Any previously pending response to a General
Query is canceled.
--8<--
Currently the timer is rearmed with new random expiration time for
every incoming query regardless of possibly already pending report.
Which is not aligned with the above RFE.
It also might happen that higher rate of incoming queries can
postpone the report after the expiration time of the first query
causing group membership loss.
Now the per interface general query timer is rearmed only
when there is no pending report already scheduled on that interface or
the newly selected expiration time is before the already pending
scheduled report.
Signed-off-by: Michal Tesar <mtesar@redhat.com>
---
net/ipv4/igmp.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 606cc3e..5fc3fd4 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -219,9 +219,14 @@ static void igmp_start_timer(struct ip_mc_list *im, int max_delay)
static void igmp_gq_start_timer(struct in_device *in_dev)
{
int tv = prandom_u32() % in_dev->mr_maxdelay;
+ unsigned long exp = jiffies + tv + 2;
+
+ if (in_dev->mr_gq_running &&
+ time_after_eq(exp, (in_dev->mr_gq_timer).expires))
+ return;
in_dev->mr_gq_running = 1;
- if (!mod_timer(&in_dev->mr_gq_timer, jiffies+tv+2))
+ if (!mod_timer(&in_dev->mr_gq_timer, exp))
in_dev_hold(in_dev);
}
--
2.5.5
^ permalink raw reply related
* RE: [PATCH net] r8152: Fix broken RX checksums.
From: Hayes Wang @ 2016-11-03 8:56 UTC (permalink / raw)
To: Mark Lord, David Miller
Cc: nic_swsd, netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <201611030159.uA31x0np004648@rtits1.realtek.com>
Mark Lord [mailto:mlord@pobox.com]
> Sent: Thursday, November 03, 2016 2:30 AM
> To: Hayes Wang; David Miller
[...]
> I have poked at it some more, and thus far it appears that it is
> only necessary to disable TCP rx checksums. The system doesn't crash
> when only IP/UDP checksums are enabled, but does when TCP checksums are on.
>
> This happens regardless of whether RX_AGG is disabled or enabled,
> and increasing/decreasing the number of RX URBs (RTL8152_MAX_RX)
> doesn't seem to affect it.
I test Raspberry Pi v1, but I couldn't boot with NFSROOT through
both onboard nic and RTL8152. I get following error.
VFS: Unable to mount root fs via NFS, trying floppy.
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
However, if I start the system without NFSROOT, I could mount the nfs fs.
Any idea?
NFS server: Fedora 24
Raspberry Pi OS: 2016-09-23-raspbian-jessie
Content of /etc/exports:
/nfsexport *(rw,sync,no_root_squash)
I change the cmdline.txt from
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1
root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline
fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
to
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1
root=/dev/nfs nfsroot=192.168.94.2:/nfsexport ip=192.168.94.22
rw rootwait quiet splash plymouth.ignore-serial-consoles
Best Regards,
Hayes
^ permalink raw reply
* [patch net-next] mlxsw: pci: Fix the FW ready mask length
From: Jiri Pirko @ 2016-11-03 8:41 UTC (permalink / raw)
To: netdev; +Cc: davem, eladr
From: Elad Raz <eladr@mellanox.com>
The system-status register is actually 16-bit wide and not 8 bit-wide.
Fixes: 233fa44bd67ae ("mlxsw: pci: Implement reset done check")
Signed-off-by: Elad Raz <eladr@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/pci_hw.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/pci_hw.h b/drivers/net/ethernet/mellanox/mlxsw/pci_hw.h
index 708736f..d147ddd 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/pci_hw.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/pci_hw.h
@@ -60,7 +60,7 @@
#define MLXSW_PCI_SW_RESET_RST_BIT BIT(0)
#define MLXSW_PCI_SW_RESET_TIMEOUT_MSECS 5000
#define MLXSW_PCI_FW_READY 0xA1844
-#define MLXSW_PCI_FW_READY_MASK 0xFF
+#define MLXSW_PCI_FW_READY_MASK 0xFFFF
#define MLXSW_PCI_FW_READY_MAGIC 0x5E
#define MLXSW_PCI_DOORBELL_SDQ_OFFSET 0x000
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower
From: Joe Perches @ 2016-11-03 8:41 UTC (permalink / raw)
To: Jes Sorensen, John Heenan
Cc: Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <wrfjzillsan3.fsf@redhat.com>
On Sun, 2016-10-30 at 19:02 -0400, Jes Sorensen wrote:
> Code is 80 characters wide, and comments are /* */ never the ugly C++
> crap.
You might look at the recent Linus Torvalds authored commit
5e467652ffef (?printk: re-organize log_output() to be more legible")
which does both of those: c99 // comments and > 80 columns.
Absolutes are for zealots.
^ permalink raw reply
* Re: [PATCH v5 5/7] net: ethernet: bgmac: device tree phy enablement
From: Rafal Milecki @ 2016-11-03 8:31 UTC (permalink / raw)
To: Jon Mason, David Miller, Rob Herring, Mark Rutland,
Florian Fainelli
Cc: netdev, bcm-kernel-feedback-list, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <1478106488-11779-6-git-send-email-jon.mason@broadcom.com>
On 11/02/2016 06:08 PM, Jon Mason wrote:
> Change the bgmac driver to allow for phy's defined by the device tree
This is a late review, I know, sorry... :(
> +static int bcma_phy_direct_connect(struct bgmac *bgmac)
> +{
> + struct fixed_phy_status fphy_status = {
> + .link = 1,
> + .speed = SPEED_1000,
> + .duplex = DUPLEX_FULL,
> + };
> + struct phy_device *phy_dev;
> + int err;
> +
> + phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, -1, NULL);
> + if (!phy_dev || IS_ERR(phy_dev)) {
> + dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
> + return -ENODEV;
> + }
> +
> + err = phy_connect_direct(bgmac->net_dev, phy_dev, bgmac_adjust_link,
> + PHY_INTERFACE_MODE_MII);
> + if (err) {
> + dev_err(bgmac->dev, "Connecting PHY failed\n");
> + return err;
> + }
> +
> + return err;
> +}
This bcma specific function looks exactly the same as...
> +static int platform_phy_direct_connect(struct bgmac *bgmac)
> +{
> + struct fixed_phy_status fphy_status = {
> + .link = 1,
> + .speed = SPEED_1000,
> + .duplex = DUPLEX_FULL,
> + };
> + struct phy_device *phy_dev;
> + int err;
> +
> + phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, -1, NULL);
> + if (!phy_dev || IS_ERR(phy_dev)) {
> + dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
> + return -ENODEV;
> + }
> +
> + err = phy_connect_direct(bgmac->net_dev, phy_dev, bgmac_adjust_link,
> + PHY_INTERFACE_MODE_MII);
> + if (err) {
> + dev_err(bgmac->dev, "Connecting PHY failed\n");
> + return err;
> + }
> +
> + return err;
> +}
This one.
Would that make sense to keep bgmac_phy_connect_direct and just use it in
bcma/platform code?
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH] e1000e: free IRQ when the link is up or down
From: Ruinskiy, Dima @ 2016-11-03 8:09 UTC (permalink / raw)
To: Tyler Baicar, Kirsher, Jeffrey T,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, okaya@codeaurora.org,
timur@codeaurora.org
In-Reply-To: <1478120896-5907-1-git-send-email-tbaicar@codeaurora.org>
>-----Original Message-----
>From: Intel-wired-lan [mailto:intel-wired-lan-bounces@lists.osuosl.org] On
>Behalf Of Tyler Baicar
>Sent: Wednesday, 02 November, 2016 23:08
>To: Kirsher, Jeffrey T; intel-wired-lan@lists.osuosl.org;
>netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
>okaya@codeaurora.org; timur@codeaurora.org
>Cc: Tyler Baicar
>Subject: [Intel-wired-lan] [PATCH] e1000e: free IRQ when the link is up or
>down
>
>Move IRQ free code so that it will happen regardless of the link state.
>Currently the e1000e driver only releases its IRQ if the link is up. This is not
>sufficient because it is possible for a link to go down without releasing the IRQ.
>A secondary bus reset can cause this case to happen.
>
>Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
>---
> drivers/net/ethernet/intel/e1000e/netdev.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
>b/drivers/net/ethernet/intel/e1000e/netdev.c
>index 7017281..36cfcb0 100644
>--- a/drivers/net/ethernet/intel/e1000e/netdev.c
>+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
>@@ -4679,12 +4679,13 @@ int e1000e_close(struct net_device *netdev)
>
> if (!test_bit(__E1000_DOWN, &adapter->state)) {
> e1000e_down(adapter, true);
>- e1000_free_irq(adapter);
>
> /* Link status message must follow this format */
> pr_info("%s NIC Link is Down\n", adapter->netdev->name);
> }
>
>+ e1000_free_irq(adapter);
>+
> napi_disable(&adapter->napi);
>
> e1000e_free_tx_resources(adapter->tx_ring);
>--
>Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
>Technologies, Inc.
>Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
>Foundation Collaborative Project.
>
>_______________________________________________
>Intel-wired-lan mailing list
>Intel-wired-lan@lists.osuosl.org
>http://lists.osuosl.org/mailman/listinfo/intel-wired-lan
This is not correct. __E1000_DOWN has nothing to do with link state. It is an internal driver status bit that indicates that device shutdown is in progress.
I would not change this code without checking very carefully the driver state machine. This can cause a whole lot of issues. Did you encounter some particular problem that is resolved by this change?
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply
* Re: [PATCH net v3] ipv4: allow local fragmentation in ip_finish_output_gso()
From: Shmulik Ladkani @ 2016-11-03 7:42 UTC (permalink / raw)
To: Lance Richardson; +Cc: netdev, fw, jtluka, hannes
In-Reply-To: <1478118977-19608-1-git-send-email-lrichard@redhat.com>
On Wed, 2 Nov 2016 16:36:17 -0400
Lance Richardson <lrichard@redhat.com> wrote:
> - /* common case: fragmentation of segments is not allowed,
> - * or seglen is <= mtu
> + /* common case: seglen is <= mtu
> */
> - if (((IPCB(skb)->flags & IPSKB_FRAG_SEGS) == 0) ||
> - skb_gso_validate_mtu(skb, mtu))
> + if (skb_gso_validate_mtu(skb, mtu))
> return ip_finish_output2(net, sk, skb);
OK.
Resembles https://patchwork.ozlabs.org/patch/644724/ ;)
> - if (skb_iif && !(df & htons(IP_DF))) {
> - /* Arrived from an ingress interface, got encapsulated, with
> - * fragmentation of encapulating frames allowed.
> - * If skb is gso, the resulting encapsulated network segments
> - * may exceed dst mtu.
> - * Allow IP Fragmentation of segments.
> - */
> - IPCB(skb)->flags |= IPSKB_FRAG_SEGS;
> - }
The only potential issue I see removing this, is that the KNOWLEDGE of
the forwarding/tunnel-bridging usecases (that require a
skb_gso_validate_mtu check) is lost.
Meaning, if one decides (as claimed in the past) that locally generated
traffic must NOT go through fragmentation validation, then no one
remembers those other valid usecases (which are very specific and not
trivial to imagine) that MUST go through it; Therefore it can easily get
broken.
Maybe we can elaborate in the comment above the call to
skb_gso_validate_mtu in ip_finish_output_gso?
Best,
Shmulik
^ permalink raw reply
* Re: [PATCH 1/2] rtl8xxxu: Fix for authentication failure
From: John Heenan @ 2016-11-03 7:10 UTC (permalink / raw)
To: Larry Finger
Cc: Jes Sorensen, Kalle Valo, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <8dba6346-332e-84e6-89b2-02033a449f25-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
On 3 November 2016 at 11:00, Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> wrote:
> On 10/30/2016 05:20 AM, John Heenan wrote:
>>
>> This fix enables the same sequence of init behaviour as the alternative
>> working driver for the wireless rtl8723bu IC at
>> https://github.com/lwfinger/rtl8723bu
>>
>> For exampe rtl8xxxu_init_device is now called each time
>> userspace wpa_supplicant is executed instead of just once when
>> modprobe is executed.
>
>
> After all the trouble you have had with your patches, I would expect you to
> use more care when composing the commit message. Note the typo in the
> paragraph above.
>
OK, the nasty games continue and the message is not getting through.
An appropriate response by a maintainer would have been to request I
revise the code according to the way it has currently and elegantly
revised in.
[PATCH v2] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC
where I use a simple pointer comparison of priv->fops with &rtl8723bu_fops.
As far as I can see there is nothing more to be done on my part code
wise. The supposed issue with matching functions, as far as I can see,
is a non issue.
If you want to comment on comments in patch messages please do so on
the above current proposed patch instead of dragging up stale and
irreelvant patch proposals to make a petty point.
Jes has now moved the goal posts, indicating all drivers for rtl8xxxu
need to be tested fro similar issues. If there are problems with other
rtl8xxxu drives then it is not my problem and has nothing to do with
me. My issue is only with the rtl8723bu driver.
Such doubts also makes it look as if there was never any proper
testing and there is no real interest in proper testing. After all
that would involve cooperation and team work.
Want concrete evidence? I actually did report problems to Jes in
private emails, AS REQUESTED, in dmesg before I started tests and
posting patches. In the emalI stated I was willing to test drivers
with printk messages. I did not even get the courtesy of a reply.
Want even more concrete evidence? Jes has some very strange comments
in his tree for his current last commit
f958b1e0806c045830d78c4287fbcddf9e5fd9d0
" This uncovered a huge bug where the old code would use struct
ieee80211_rate.flags to test for rate parameters, which is always
zero, instead of the flags value from struct ieee80211_tx_rate.
"Time to find a brown paper bag :("
John Heenan
>> Along with 'Fix for bogus data used to determine macpower',
>> wpa_supplicant now reliably and successfully authenticates.
>
>
> I'm not sure this paragraph belongs in the permanent commit record.
>
>> For rtl8xxxu-devel branch of
>> git.kernel.org/pub/scm/linux/kernel/git/jes/linux.git
>
>
> I know this line does not belong. If you want to include information like
> this, include it after a line containing "---". Those lines will be
> available to reviewers and maintainers, but will be stripped before it gets
> included in the code base.
>
>
>> Signed-off-by: John Heenan <john-AMlJbUfTsso@public.gmane.org>
>> ---
>> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 9 +++++----
>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
>> b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
>> index 04141e5..f25b4df 100644
>> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
>> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
>> @@ -5779,6 +5779,11 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
>>
>> ret = 0;
>>
>> + ret = rtl8xxxu_init_device(hw);
>> + if (ret)
>> + goto error_out;
>> +
>> +
>> init_usb_anchor(&priv->rx_anchor);
>> init_usb_anchor(&priv->tx_anchor);
>> init_usb_anchor(&priv->int_anchor);
>> @@ -6080,10 +6085,6 @@ static int rtl8xxxu_probe(struct usb_interface
>> *interface,
>> goto exit;
>> }
>>
>> - ret = rtl8xxxu_init_device(hw);
>> - if (ret)
>> - goto exit;
>> -
>> hw->wiphy->max_scan_ssids = 1;
>> hw->wiphy->max_scan_ie_len = IEEE80211_MAX_DATA_LEN;
>> hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION);
>>
>
> I will let Jes comment on any side effects of this code change.
>
> Larry
>
> --
> If I was stranded on an island and the only way to get off
> the island was to make a pretty UI, I’d die there.
>
> Linus Torvalds
^ permalink raw reply
* Re: [PATCH RFC 0/2] ethtool: Add actual port speed reporting
From: Or Gerlitz @ 2016-11-03 7:02 UTC (permalink / raw)
To: Gal Pressman
Cc: Linux Netdev List, John W. Linville, Vidya Sagar Ravipati,
Saeed Mahameed, David Decotigny, Ben Hutchings
In-Reply-To: <1478100914-23610-1-git-send-email-galp@mellanox.com>
On Wed, Nov 2, 2016 at 5:35 PM, Gal Pressman <galp@mellanox.com> wrote:
> In some cases such as virtual machines and multi functions (SR-IOV), the actual
> bandwidth exposed for each machine is not accurately shown in ethtool.
You mean that if you rate-limit a VF from the host they will be able
to actually query that
and report it to their OS?
^ permalink raw reply
* Re: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net
From: John Fastabend @ 2016-11-03 6:44 UTC (permalink / raw)
To: Michael S. Tsirkin, Shrijeet Mukherjee
Cc: Jesper Dangaard Brouer, Thomas Graf, Alexei Starovoitov,
Jakub Kicinski, David Miller, alexander.duyck, shrijeet, tom,
netdev, Roopa Prabhu, Nikolay Aleksandrov
In-Reply-To: <20161103041145.arylaxxssbdylfwn@redhat.com>
On 16-11-02 09:11 PM, Michael S. Tsirkin wrote:
> On Wed, Nov 02, 2016 at 06:28:34PM -0700, Shrijeet Mukherjee wrote:
>>> -----Original Message-----
>>> From: Jesper Dangaard Brouer [mailto:brouer@redhat.com]
>>> Sent: Wednesday, November 2, 2016 7:27 AM
>>> To: Thomas Graf <tgraf@suug.ch>
>>> Cc: Shrijeet Mukherjee <shm@cumulusnetworks.com>; Alexei Starovoitov
>>> <alexei.starovoitov@gmail.com>; Jakub Kicinski <kubakici@wp.pl>; John
>>> Fastabend <john.fastabend@gmail.com>; David Miller
>>> <davem@davemloft.net>; alexander.duyck@gmail.com; mst@redhat.com;
>>> shrijeet@gmail.com; tom@herbertland.com; netdev@vger.kernel.org;
>>> Roopa Prabhu <roopa@cumulusnetworks.com>; Nikolay Aleksandrov
>>> <nikolay@cumulusnetworks.com>; brouer@redhat.com
>>> Subject: Re: [PATCH net-next RFC WIP] Patch for XDP support for
>> virtio_net
>>>
>>> On Sat, 29 Oct 2016 13:25:14 +0200
>>> Thomas Graf <tgraf@suug.ch> wrote:
>>>
>>>> On 10/28/16 at 08:51pm, Shrijeet Mukherjee wrote:
>>>>> Generally agree, but SRIOV nics with multiple queues can end up in a
>>>>> bad spot if each buffer was 4K right ? I see a specific page pool to
>>>>> be used by queues which are enabled for XDP as the easiest to swing
>>>>> solution that way the memory overhead can be restricted to enabled
>>>>> queues and shared access issues can be restricted to skb's using
>> that
>>> pool no ?
>>>
>>> Yes, that is why that I've been arguing so strongly for having the
>> flexibility to
>>> attach a XDP program per RX queue, as this only change the memory model
>>> for this one queue.
>>>
>>>
>>>> Isn't this clearly a must anyway? I may be missing something
>>>> fundamental here so please enlighten me :-)
>>>>
>>>> If we dedicate a page per packet, that could translate to 14M*4K worth
>>>> of memory being mapped per second for just a 10G NIC under DoS attack.
>>>> How can one protect such as system? Is the assumption that we can
>>>> always drop such packets quickly enough before we start dropping
>>>> randomly due to memory pressure? If a handshake is required to
>>>> determine validity of a packet then that is going to be difficult.
>>>
>>> Under DoS attacks you don't run out of memory, because a diverse set of
>>> socket memory limits/accounting avoids that situation. What does happen
>>> is the maximum achievable PPS rate is directly dependent on the
>>> time you spend on each packet. This use of CPU resources (and
>>> hitting mem-limits-safe-guards) push-back on the drivers speed to
>> process
>>> the RX ring. In effect, packets are dropped in the NIC HW as RX-ring
>> queue
>>> is not emptied fast-enough.
>>>
>>> Given you don't control what HW drops, the attacker will "successfully"
>>> cause your good traffic to be among the dropped packets.
>>>
>>> This is where XDP change the picture. If you can express (by eBPF) a
>> filter
>>> that can separate "bad" vs "good" traffic, then you can take back
>> control.
>>> Almost like controlling what traffic the HW should drop.
>>> Given the cost of XDP-eBPF filter + serving regular traffic does not use
>> all of
>>> your CPU resources, you have overcome the attack.
>>>
>>> --
>> Jesper, John et al .. to make this a little concrete I am going to spin
>> up a v2 which has only bigbuffers mode enabled for xdp acceleration, all
>> other modes will reject the xdp ndo ..
>>
>> Do we have agreement on that model ?
>>
>> It will need that all vhost implementations will need to start with
>> mergeable buffers disabled to get xdp goodness, but that sounds like a
>> safe thing to do for now ..
>
> It's ok for experimentation, but really after speaking with Alexei it's
> clear to me that xdp should have a separate code path in the driver,
> e.g. the separation between modes is something that does not
> make sense for xdp.
>
> The way I imagine it working:
OK I tried to make some sense out of this and get it working,
>
> - when XDP is attached disable all LRO using VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET
> (not used by driver so far, designed to allow dynamic LRO control with
> ethtool)
I see there is a UAPI bit for this but I guess we also need to add
support to vhost as well? Seems otherwise we may just drop a bunch
of packets on the floor out of handle_rx() when recvmsg returns larger
than a page size. Or did I read this wrong...
> - start adding page-sized buffers
I started to mangle add_recvbuf_big() and receive_big() here and this
didn't seem too bad.
> - do something with non-page-sized buffers added previously - what
> exactly? copy I guess? What about LRO packets that are too large -
> can we drop or can we split them up?
hmm not sure I understand this here. With LRO disabled and mergeable
buffers disabled all packets should fit in a page correct?
With LRO enabled case I guess to start with we block XDP from being
loaded for the same reason we don't allow jumbo frames on physical
nics.
>
> I'm fine with disabling XDP for some configurations as the first step,
> and we can add that support later.
>
In order for this to work though I guess we need to be able to
dynamically disable mergeable buffers at the moment I just commented
it out of the features list and fixed up virtio_has_features so it
wont bug_on.
> Ideas about mergeable buffers (optional):
>
> At the moment mergeable buffers can't be disabled dynamically.
> They do bring a small benefit for XDP if host MTU is large (see below)
> and aren't hard to support:
> - if header is by itself skip 1st page
> - otherwise copy all data into first page
> and it's nicer not to add random limitations that require guest reboot.
> It might make sense to add a command that disables/enabled
> mergeable buffers dynamically but that's for newer hosts.
Yep it seems disabling mergeable buffers solves this but didn't look at
it too closely. I'll look closer tomorrow.
>
> Spec does not require it but in practice most hosts put all data
> in the 1st page or all in the 2nd page so the copy will be nop
> for these cases.
>
> Large host MTU - newer hosts report the host MTU, older ones don't.
> Using mergeable buffers we can at least detect this case
> (and then what? drop I guess).
>
The physical nics just refuse to load XDP with large MTU. Any reason
not to negotiate the mtu with the guest so that the guest can force
this?
>
>
>
Thanks,
John
^ permalink raw reply
* Grant Benefit
From: Mrs Julie Leach @ 2016-11-03 6:08 UTC (permalink / raw)
To: Recipients
You are a recipient to Mrs Julie Leach Donation of $2 million USD. Contact (julieleach104@gmail.com) for claims
^ 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