* Re: [PATCH net-next] net: Remove unused tcp_set_state tracepoint
From: David Miller @ 2018-04-16 23:02 UTC (permalink / raw)
To: rdna; +Cc: rostedt, laoar.shao, netdev, kernel-team
In-Reply-To: <20180416220713.3339568-1-rdna@fb.com>
From: Andrey Ignatov <rdna@fb.com>
Date: Mon, 16 Apr 2018 15:07:13 -0700
> This tracepoint was replaced by inet_sock_set_state in 563e0bb and not
> used anywhere in the kernel anymore. Remove it.
>
> Signed-off-by: Andrey Ignatov <rdna@fb.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH 08/10] net: ax88796: Make reset more robust on AX88796B
From: Andrew Lunn @ 2018-04-16 23:12 UTC (permalink / raw)
To: Michael Schmitz
Cc: netdev, linux-m68k, Michael.Karcher, John Paul Adrian Glaubitz,
Michael Karcher
In-Reply-To: <1523916285-6057-9-git-send-email-schmitzmic@gmail.com>
On Tue, Apr 17, 2018 at 10:04:43AM +1200, Michael Schmitz wrote:
> From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
>
> The AX88796B as installed on the X-Surf-100 does not recognize a MII reset
> request if the previous write to the MII control register also was a reset
> request. So a dummy write to the control register makes the soft reset in
> the PHY initialization code work.
>
> Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
> ---
> drivers/net/ethernet/8390/ax88796.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ethernet/8390/ax88796.c b/drivers/net/ethernet/8390/ax88796.c
> index 6af9aca..a2f9a09 100644
> --- a/drivers/net/ethernet/8390/ax88796.c
> +++ b/drivers/net/ethernet/8390/ax88796.c
> @@ -374,6 +374,10 @@ static int ax_mii_probe(struct net_device *dev)
> return -ENODEV;
> }
>
> + /* write a non-reset pattern to the control register to
> + * re-arm the reset request detection logic (needed on AX88796B)
> + */
> + phy_write(phy_dev, MII_BMCR, 0);
This should really be fixed in the PHY driver, not the MAC.
Andrew
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: allow dwmac-sun8i to use other devices' exported regmap
From: Icenowy Zheng @ 2018-04-16 23:17 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Maxime Ripard,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai, Corentin Labbe,
Giuseppe Cavallaro
In-Reply-To: <20180416184745.tqxyvojtcbage4fu@rob-hp-laptop>
于 2018年4月17日 GMT+08:00 上午2:47:45, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 写到:
>On Wed, Apr 11, 2018 at 10:16:37PM +0800, Icenowy Zheng wrote:
>> On some Allwinner SoCs the EMAC clock register needed by dwmac-sun8i
>is
>> in another device's memory space. In this situation dwmac-sun8i can
>use
>> a regmap exported by the other device with only the EMAC clock
>register.
>
>If this is a clock, then why not use the clock binding?
EMAC clock register is only the datasheet name. It contains
MII mode selection and delay chain configuration.
>
>>
>> Document this situation in the dwmac-sun8i device tree binding
>> documentation.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
>b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
>> index 3d6d5fa0c4d5..0c5f63a80617 100644
>> --- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
>> +++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
>> @@ -20,8 +20,9 @@ Required properties:
>> - phy-handle: See ethernet.txt
>> - #address-cells: shall be 1
>> - #size-cells: shall be 0
>> -- syscon: A phandle to the syscon of the SoC with one of the
>following
>> - compatible string:
>> +- syscon: A phandle to a device which exports the EMAC clock
>register as a
>> + regmap or to the syscon of the SoC with one of the following
>compatible
>> + string:
>> - allwinner,sun8i-h3-system-controller
>> - allwinner,sun8i-v3s-system-controller
>> - allwinner,sun50i-a64-system-controller
>> --
>> 2.15.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree"
>in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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: [PATCH net-next 1/2] openvswitch: Add conntrack limit netlink definition
From: Gregory Rose @ 2018-04-16 23:52 UTC (permalink / raw)
To: Yi-Hung Wei, netdev
In-Reply-To: <1523902550-10767-2-git-send-email-yihung.wei@gmail.com>
On 4/16/2018 11:15 AM, Yi-Hung Wei wrote:
> Define netlink messages and attributes to support user kernel
> communication that using conntrack limit feature.
s/using/uses the/
>
> Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com>
> ---
> include/uapi/linux/openvswitch.h | 62 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 62 insertions(+)
>
> diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
> index 713e56ce681f..ca63c16375ce 100644
> --- a/include/uapi/linux/openvswitch.h
> +++ b/include/uapi/linux/openvswitch.h
> @@ -937,4 +937,66 @@ enum ovs_meter_band_type {
>
> #define OVS_METER_BAND_TYPE_MAX (__OVS_METER_BAND_TYPE_MAX - 1)
>
> +/* Conntrack limit */
> +#define OVS_CT_LIMIT_FAMILY "ovs_ct_limit"
> +#define OVS_CT_LIMIT_MCGROUP "ovs_ct_limit"
> +#define OVS_CT_LIMIT_VERSION 0x1
> +
> +enum ovs_ct_limit_cmd {
> + OVS_CT_LIMIT_CMD_UNSPEC,
> + OVS_CT_LIMIT_CMD_SET, /* Add or modify ct limit. */
> + OVS_CT_LIMIT_CMD_DEL, /* Delete ct limit. */
> + OVS_CT_LIMIT_CMD_GET /* Get ct limit. */
> +};
> +
> +enum ovs_ct_limit_attr {
> + OVS_CT_LIMIT_ATTR_UNSPEC,
> + OVS_CT_LIMIT_ATTR_OPTION, /* Nested OVS_CT_LIMIT_ATTR_* */
> + __OVS_CT_LIMIT_ATTR_MAX
> +};
> +
> +#define OVS_CT_LIMIT_ATTR_MAX (__OVS_CT_LIMIT_ATTR_MAX - 1)
> +
> +/**
> + * @OVS_CT_ZONE_LIMIT_ATTR_SET_REQ: Contains either
> + * OVS_CT_ZONE_LIMIT_ATTR_DEFAULT_LIMIT or a pair of
> + * OVS_CT_ZONE_LIMIT_ATTR_ZONE and OVS_CT_ZONE_LIMIT_ATTR_LIMIT.
> + * @OVS_CT_ZONE_LIMIT_ATTR_DEL_REQ: Contains OVS_CT_ZONE_LIMIT_ATTR_ZONE.
> + * @OVS_CT_ZONE_LIMIT_ATTR_GET_REQ: Contains OVS_CT_ZONE_LIMIT_ATTR_ZONE.
> + * @OVS_CT_ZONE_LIMIT_ATTR_GET_RLY: Contains either
> + * OVS_CT_ZONE_LIMIT_ATTR_DEFAULT_LIMIT or a triple of
> + * OVS_CT_ZONE_LIMIT_ATTR_ZONE, OVS_CT_ZONE_LIMIT_ATTR_LIMIT and
> + * OVS_CT_ZONE_LIMIT_ATTR_COUNT.
> + */
> +enum ovs_ct_limit_option_attr {
> + OVS_CT_LIMIT_OPTION_ATTR_UNSPEC,
> + OVS_CT_ZONE_LIMIT_ATTR_SET_REQ, /* Nested OVS_CT_ZONE_LIMIT_ATTR_*
> + * attributes. */
> + OVS_CT_ZONE_LIMIT_ATTR_DEL_REQ, /* Nested OVS_CT_ZONE_LIMIT_ATTR_*
> + * attributes. */
> + OVS_CT_ZONE_LIMIT_ATTR_GET_REQ, /* Nested OVS_CT_ZONE_LIMIT_ATTR_*
> + * attributes. */
> + OVS_CT_ZONE_LIMIT_ATTR_GET_RLY, /* Nested OVS_CT_ZONE_LIMIT_ATTR_*
> + * attributes. */
> + __OVS_CT_LIMIT_OPTION_ATTR_MAX
> +};
> +
> +#define OVS_CT_LIMIT_OPTION_ATTR_MAX (__OVS_CT_LIMIT_OPTION_ATTR_MAX - 1)
> +
> +enum ovs_ct_zone_limit_attr {
> + OVS_CT_ZONE_LIMIT_ATTR_UNSPEC,
> + OVS_CT_ZONE_LIMIT_ATTR_DEFAULT_LIMIT, /* u32 default conntrack limit
> + * for all zones. */
> + OVS_CT_ZONE_LIMIT_ATTR_ZONE, /* u16 conntrack zone id. */
> + OVS_CT_ZONE_LIMIT_ATTR_LIMIT, /* u32 max number of conntrack
> + * entries allowed in the
> + * corresponding zone. */
> + OVS_CT_ZONE_LIMIT_ATTR_COUNT, /* u32 number of conntrack
> + * entries in the corresponding
> + * zone. */
> + __OVS_CT_ZONE_LIMIT_ATTR_MAX
> +};
> +
> +#define OVS_CT_ZONE_LIMIT_ATTR_MAX (__OVS_CT_ZONE_LIMIT_ATTR_MAX - 1)
> +
> #endif /* _LINUX_OPENVSWITCH_H */
Is this something that other users can use? I searched around and
didn't see any mention
of it for other kernel users but perhaps I missed something?
Thanks,
- Greg
^ permalink raw reply
* Re: [PATCH bpf-next 1/3] bpftool: Add missing prog types and attach types
From: Jakub Kicinski @ 2018-04-16 23:52 UTC (permalink / raw)
To: Andrey Ignatov; +Cc: ast, daniel, netdev, kernel-team
In-Reply-To: <5dd2cc619f2eed089e7da9bd7f64031278d6b4fe.1523914232.git.rdna@fb.com>
On Mon, 16 Apr 2018 14:41:57 -0700, Andrey Ignatov wrote:
> diff --git a/tools/bpf/bpftool/cgroup.c b/tools/bpf/bpftool/cgroup.c
> index cae32a6..8689916 100644
> --- a/tools/bpf/bpftool/cgroup.c
> +++ b/tools/bpf/bpftool/cgroup.c
> @@ -16,15 +16,28 @@
> #define HELP_SPEC_ATTACH_FLAGS \
> "ATTACH_FLAGS := { multi | override }"
>
> -#define HELP_SPEC_ATTACH_TYPES \
> - "ATTACH_TYPE := { ingress | egress | sock_create | sock_ops | device }"
> +#define HELP_SPEC_ATTACH_TYPES \
> + " ATTACH_TYPE := { ingress | egress | sock_create |\n" \
> + " sock_ops | stream_parser |\n" \
> + " stream_verdict | device | msg_verdict |\n" \
> + " bind4 | bind6 | connect4 | connect6 |\n" \
> + " post_bind4 | post_bind6 }"
>
Would you mind updating the man page in Documentation/ as well?
Thanks!
^ permalink raw reply
* Re: [PATCH 02/10] net: ax88796: Attach MII bus only when open
From: Michael Schmitz @ 2018-04-16 23:53 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, Linux/m68k, Michael Karcher, Michael Karcher,
Michael Karcher
In-Reply-To: <20180416225900.GA23474@lunn.ch>
Hi Andrew,
thank you for reviewing this series!
On Tue, Apr 17, 2018 at 10:59 AM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Tue, Apr 17, 2018 at 10:04:37AM +1200, Michael Schmitz wrote:
>> From: Michael Karcher <debian@mkarcher.dialup.fu-berlin.de>
>>
>> Call ax_mii_init in ax_open(), and unregister/remove mdiobus resources
>> in ax_close().
>>
>> This is needed to be able to unload the module, as the module is busy
>> while the MII bus is attached.
>>
>> Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
>> Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
>> ---
>> drivers/net/ethernet/8390/ax88796.c | 13 +++++++++----
>> 1 files changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/8390/ax88796.c b/drivers/net/ethernet/8390/ax88796.c
>> index 2a256aa..f7b8911 100644
>> --- a/drivers/net/ethernet/8390/ax88796.c
>> +++ b/drivers/net/ethernet/8390/ax88796.c
>> @@ -79,6 +79,8 @@
>>
>> static u32 ax_msg_enable;
>>
>> +static int ax_mii_init(struct net_device *dev);
>
> Hi Michael
>
> We try to avoid forward declarations. Please can you move
> ax_mii_init() so this is not needed.
Done that - had to move the entire bitbang stuff along with
ax_mii_init() though.
>> +
>> /* device private data */
>>
>> struct ax_device {
>> @@ -396,6 +398,10 @@ static int ax_open(struct net_device *dev)
>>
>> netdev_dbg(dev, "open\n");
>>
>> + ret = ax_mii_init(dev);
>> + if (ret)
>> + goto failed_request_irq;
>> +
>> ret = request_irq(dev->irq, ax_ei_interrupt, ax->irqflags,
>> dev->name, dev);
>> if (ret)
>
> You are missing some cleanup on error at the end of ax_open().
> It was also missing before.
Yep, that's addressed in patch 7 of this series. I'll fold that into
this one for clarity.
Cheers,
Michael
>
> Andrew
^ permalink raw reply
* Re: [PATCH bpf-next 1/3] bpftool: Add missing prog types and attach types
From: Andrey Ignatov @ 2018-04-16 23:57 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: ast, daniel, netdev, kernel-team
In-Reply-To: <20180416165250.0c907e90@cakuba.netronome.com>
Jakub Kicinski <kubakici@wp.pl> [Mon, 2018-04-16 16:53 -0700]:
> On Mon, 16 Apr 2018 14:41:57 -0700, Andrey Ignatov wrote:
> > diff --git a/tools/bpf/bpftool/cgroup.c b/tools/bpf/bpftool/cgroup.c
> > index cae32a6..8689916 100644
> > --- a/tools/bpf/bpftool/cgroup.c
> > +++ b/tools/bpf/bpftool/cgroup.c
> > @@ -16,15 +16,28 @@
> > #define HELP_SPEC_ATTACH_FLAGS \
> > "ATTACH_FLAGS := { multi | override }"
> >
> > -#define HELP_SPEC_ATTACH_TYPES \
> > - "ATTACH_TYPE := { ingress | egress | sock_create | sock_ops | device }"
> > +#define HELP_SPEC_ATTACH_TYPES \
> > + " ATTACH_TYPE := { ingress | egress | sock_create |\n" \
> > + " sock_ops | stream_parser |\n" \
> > + " stream_verdict | device | msg_verdict |\n" \
> > + " bind4 | bind6 | connect4 | connect6 |\n" \
> > + " post_bind4 | post_bind6 }"
> >
>
> Would you mind updating the man page in Documentation/ as well?
Sure. Will update and send v2.
--
Andrey Ignatov
^ permalink raw reply
* Re: [iproute PATCH] iproute: Abort if nexthop cannot be parsed
From: Stephen Hemminger @ 2018-04-17 0:00 UTC (permalink / raw)
To: Jakub Sitnicki; +Cc: netdev
In-Reply-To: <20180411094311.21097-1-jkbs@redhat.com>
On Wed, 11 Apr 2018 11:43:11 +0200
Jakub Sitnicki <jkbs@redhat.com> wrote:
> Attempt to add a multipath route where a nexthop definition refers to a
> non-existent device causes 'ip' to crash and burn due to stack buffer
> overflow:
>
> # ip -6 route add fd00::1/64 nexthop dev fake1
> Cannot find device "fake1"
> Cannot find device "fake1"
> Cannot find device "fake1"
> ...
> Segmentation fault (core dumped)
>
> Don't ignore errors from the helper routine that parses the nexthop
> definition, and abort immediately if parsing fails.
>
> Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
Makes sense. Applied
^ permalink raw reply
* Re: [PATCH net-next 2/2] openvswitch: Support conntrack zone limit
From: Gregory Rose @ 2018-04-17 0:00 UTC (permalink / raw)
To: Yi-Hung Wei, netdev
In-Reply-To: <1523902550-10767-3-git-send-email-yihung.wei@gmail.com>
On 4/16/2018 11:15 AM, Yi-Hung Wei wrote:
> Currently, nf_conntrack_max is used to limit the maximum number of
> conntrack entries in the conntrack table for every network namespace.
> For the VMs and containers that reside in the same namespace,
> they share the same conntrack table, and the total # of conntrack entries
> for all the VMs and containers are limited by nf_conntrack_max. In this
> case, if one of the VM/container abuses the usage the conntrack entries,
> it blocks the others to commit valid conntrack entry into the conntrack
s/to commit/from committing/
s/entry/entries/
> table. Even if we can possibly put the VM in different network namespace,
> the current nf_conntrack_max configuration is kind of rigid that we cannot
> limit different VM/container to have different # conntrack entries.
>
> To address the aforementioned issue, this patch proposes to have a
> fine-grained mechanism that could further limit the # of conntrack entries
> per-zone. For example, we can designate different zone to different VM,
> and set conntrack limit to each zone. By providing this isolation, a
> mis-behaved VM only consumes the conntrack entries in its own zone, and
> it will not influence other well-behaved VMs. Moreover, the users can
> set various conntrack limit to different zone based on their preference.
>
> The proposed implementation utilizes Netfilter's nf_conncount backend
> to count the number of connections in a particular zone. If the number of
> connection is above a configured limitation, ovs will return ENOMEM to the
> userspace. If userspace does not configure the zone limit, the limit
> defaults to zero that is no limitation, which is backward compatible to
> the behavior without this patch.
>
> The following high leve APIs are provided to the userspace:
> - OVS_CT_LIMIT_CMD_SET:
> * set default connection limit for all zones
> * set the connection limit for a particular zone
> - OVS_CT_LIMIT_CMD_DEL:
> * remove the connection limit for a particular zone
> - OVS_CT_LIMIT_CMD_GET:
> * get the default connection limit for all zones
> * get the connection limit for a particular zone
>
> Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com>
I think this is a great idea but I suggest porting to the iproute2 package
so everyone can use it. Then git rid of the OVS specific prefixes.
Presuming of course that the conntrack connection
limit backend works there as well I guess. If it doesn't, then I'd
suggest extending
it. This is a nice feature for all users in my opinion and then OVS
can take advantage of it as well.
Thanks!
- Greg
> ---
> net/openvswitch/Kconfig | 3 +-
> net/openvswitch/conntrack.c | 497 +++++++++++++++++++++++++++++++++++++++++++-
> net/openvswitch/conntrack.h | 9 +-
> net/openvswitch/datapath.c | 7 +-
> net/openvswitch/datapath.h | 1 +
> 5 files changed, 511 insertions(+), 6 deletions(-)
>
> diff --git a/net/openvswitch/Kconfig b/net/openvswitch/Kconfig
> index 2650205cdaf9..89da9512ec1e 100644
> --- a/net/openvswitch/Kconfig
> +++ b/net/openvswitch/Kconfig
> @@ -9,7 +9,8 @@ config OPENVSWITCH
> (NF_CONNTRACK && ((!NF_DEFRAG_IPV6 || NF_DEFRAG_IPV6) && \
> (!NF_NAT || NF_NAT) && \
> (!NF_NAT_IPV4 || NF_NAT_IPV4) && \
> - (!NF_NAT_IPV6 || NF_NAT_IPV6)))
> + (!NF_NAT_IPV6 || NF_NAT_IPV6) && \
> + (!NETFILTER_CONNCOUNT || NETFILTER_CONNCOUNT)))
> select LIBCRC32C
> select MPLS
> select NET_MPLS_GSO
> diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
> index c5904f629091..2f51da91d056 100644
> --- a/net/openvswitch/conntrack.c
> +++ b/net/openvswitch/conntrack.c
> @@ -17,7 +17,9 @@
> #include <linux/udp.h>
> #include <linux/sctp.h>
> #include <net/ip.h>
> +#include <net/genetlink.h>
> #include <net/netfilter/nf_conntrack_core.h>
> +#include <net/netfilter/nf_conntrack_count.h>
> #include <net/netfilter/nf_conntrack_helper.h>
> #include <net/netfilter/nf_conntrack_labels.h>
> #include <net/netfilter/nf_conntrack_seqadj.h>
> @@ -76,6 +78,38 @@ struct ovs_conntrack_info {
> #endif
> };
>
> +#if IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)
> +#define OVS_CT_LIMIT_UNLIMITED 0
> +#define OVS_CT_LIMIT_DEFAULT OVS_CT_LIMIT_UNLIMITED
> +#define CT_LIMIT_HASH_BUCKETS 512
> +
> +struct ovs_ct_limit {
> + /* Elements in ovs_ct_limit_info->limits hash table */
> + struct hlist_node hlist_node;
> + struct rcu_head rcu;
> + u16 zone;
> + u32 limit;
> +};
> +
> +struct ovs_ct_limit_info {
> + u32 default_limit;
> + struct hlist_head *limits;
> + struct nf_conncount_data *data __aligned(8);
> +};
> +
> +static const struct nla_policy ct_limit_policy[OVS_CT_LIMIT_ATTR_MAX + 1] = {
> + [OVS_CT_LIMIT_ATTR_OPTION] = { .type = NLA_NESTED, },
> +};
> +
> +static const struct nla_policy
> + ct_zone_limit_policy[OVS_CT_ZONE_LIMIT_ATTR_MAX + 1] = {
> + [OVS_CT_ZONE_LIMIT_ATTR_DEFAULT_LIMIT] = { .type = NLA_U32, },
> + [OVS_CT_ZONE_LIMIT_ATTR_ZONE] = { .type = NLA_U16, },
> + [OVS_CT_ZONE_LIMIT_ATTR_LIMIT] = { .type = NLA_U32, },
> + [OVS_CT_ZONE_LIMIT_ATTR_COUNT] = { .type = NLA_U32, },
> +};
> +#endif
> +
> static bool labels_nonzero(const struct ovs_key_ct_labels *labels);
>
> static void __ovs_ct_free_action(struct ovs_conntrack_info *ct_info);
> @@ -1036,6 +1070,94 @@ static bool labels_nonzero(const struct ovs_key_ct_labels *labels)
> return false;
> }
>
> +#if IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)
> +static struct hlist_head *ct_limit_hash_bucket(
> + const struct ovs_ct_limit_info *info, u16 zone)
> +{
> + return &info->limits[zone & (CT_LIMIT_HASH_BUCKETS - 1)];
> +}
> +
> +/* Call with ovs_mutex */
> +static void ct_limit_set(const struct ovs_ct_limit_info *info,
> + struct ovs_ct_limit *new_ct_limit)
> +{
> + struct ovs_ct_limit *ct_limit;
> + struct hlist_head *head;
> +
> + head = ct_limit_hash_bucket(info, new_ct_limit->zone);
> + hlist_for_each_entry_rcu(ct_limit, head, hlist_node) {
> + if (ct_limit->zone == new_ct_limit->zone) {
> + hlist_replace_rcu(&ct_limit->hlist_node,
> + &new_ct_limit->hlist_node);
> + kfree_rcu(ct_limit, rcu);
> + return;
> + }
> + }
> +
> + hlist_add_head_rcu(&new_ct_limit->hlist_node, head);
> +}
> +
> +/* Call with ovs_mutex */
> +static void ct_limit_del(const struct ovs_ct_limit_info *info, u16 zone)
> +{
> + struct ovs_ct_limit *ct_limit;
> + struct hlist_head *head;
> +
> + head = ct_limit_hash_bucket(info, zone);
> + hlist_for_each_entry_rcu(ct_limit, head, hlist_node) {
> + if (ct_limit->zone == zone) {
> + hlist_del_rcu(&ct_limit->hlist_node);
> + kfree_rcu(ct_limit, rcu);
> + return;
> + }
> + }
> +}
> +
> +/* Call with RCU read lock */
> +static u32 ct_limit_get(const struct ovs_ct_limit_info *info, u16 zone)
> +{
> + struct ovs_ct_limit *ct_limit;
> + struct hlist_head *head;
> +
> + head = ct_limit_hash_bucket(info, zone);
> + hlist_for_each_entry_rcu(ct_limit, head, hlist_node) {
> + if (ct_limit->zone == zone)
> + return ct_limit->limit;
> + }
> +
> + return info->default_limit;
> +}
> +
> +static int ovs_ct_check_limit(struct net *net,
> + const struct ovs_conntrack_info *info,
> + const struct nf_conntrack_tuple *tuple)
> +{
> + struct ovs_net *ovs_net = net_generic(net, ovs_net_id);
> + const struct ovs_ct_limit_info *ct_limit_info = ovs_net->ct_limit_info;
> + u32 per_zone_limit, connections;
> + u32 conncount_key[5];
> +
> + conncount_key[0] = info->zone.id;
> +
> + rcu_read_lock();
> + per_zone_limit = ct_limit_get(ct_limit_info, info->zone.id);
> + if (per_zone_limit == OVS_CT_LIMIT_UNLIMITED) {
> + rcu_read_unlock();
> + return 0;
> + }
> +
> + connections = nf_conncount_count(net, ct_limit_info->data,
> + conncount_key, tuple, &info->zone);
> + if (connections > per_zone_limit) {
> + rcu_read_unlock();
> + return -ENOMEM;
> + }
> +
> + rcu_read_unlock();
> + return 0;
> +}
> +#endif
> +
> /* Lookup connection and confirm if unconfirmed. */
> static int ovs_ct_commit(struct net *net, struct sw_flow_key *key,
> const struct ovs_conntrack_info *info,
> @@ -1054,6 +1176,13 @@ static int ovs_ct_commit(struct net *net, struct sw_flow_key *key,
> if (!ct)
> return 0;
>
> +#if IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)
> + err = ovs_ct_check_limit(net, info,
> + &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple);
> + if (err)
> + return err;
> +#endif
> +
> /* Set the conntrack event mask if given. NEW and DELETE events have
> * their own groups, but the NFNLGRP_CONNTRACK_UPDATE group listener
> * typically would receive many kinds of updates. Setting the event
> @@ -1655,7 +1784,363 @@ static void __ovs_ct_free_action(struct ovs_conntrack_info *ct_info)
> nf_ct_tmpl_free(ct_info->ct);
> }
>
> -void ovs_ct_init(struct net *net)
> +#if IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)
> +static int ovs_ct_limit_init(struct net *net, struct ovs_net *ovs_net)
> +{
> + int i;
> +
> + ovs_net->ct_limit_info = kmalloc(sizeof *ovs_net->ct_limit_info,
> + GFP_KERNEL);
> + if (!ovs_net->ct_limit_info)
> + return -ENOMEM;
> +
> + ovs_net->ct_limit_info->default_limit = OVS_CT_LIMIT_DEFAULT;
> + ovs_net->ct_limit_info->limits =
> + kmalloc_array(CT_LIMIT_HASH_BUCKETS, sizeof(struct hlist_head),
> + GFP_KERNEL);
> + if (!ovs_net->ct_limit_info->limits) {
> + kfree(ovs_net->ct_limit_info);
> + return -ENOMEM;
> + }
> +
> + for (i = 0; i < CT_LIMIT_HASH_BUCKETS; i++)
> + INIT_HLIST_HEAD(&ovs_net->ct_limit_info->limits[i]);
> +
> + ovs_net->ct_limit_info->data =
> + nf_conncount_init(net, NFPROTO_INET, sizeof(u32));
> +
> + if (IS_ERR(ovs_net->ct_limit_info->data)) {
> + kfree(ovs_net->ct_limit_info->limits);
> + kfree(ovs_net->ct_limit_info);
> + return PTR_ERR(ovs_net->ct_limit_info->data);
> + }
> + return 0;
> +}
> +
> +static void ovs_ct_limit_exit(struct net *net, struct ovs_net *ovs_net)
> +{
> + const struct ovs_ct_limit_info *info = ovs_net->ct_limit_info;
> + int i;
> +
> + nf_conncount_destroy(net, NFPROTO_INET, info->data);
> + for (i = 0; i < CT_LIMIT_HASH_BUCKETS; ++i) {
> + struct hlist_head *head = &info->limits[i];
> + struct ovs_ct_limit *ct_limit;
> +
> + hlist_for_each_entry_rcu(ct_limit, head, hlist_node)
> + kfree_rcu(ct_limit, rcu);
> + }
> + kfree(ovs_net->ct_limit_info->limits);
> + kfree(ovs_net->ct_limit_info);
> +}
> +
> +static struct sk_buff *
> +ovs_ct_limit_cmd_reply_start(struct genl_info *info, u8 cmd,
> + struct ovs_header **ovs_reply_header)
> +{
> + struct sk_buff *skb;
> + struct ovs_header *ovs_header = info->userhdr;
> +
> + skb = genlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> + if (!skb)
> + return ERR_PTR(-ENOMEM);
> +
> + *ovs_reply_header = genlmsg_put(skb, info->snd_portid,
> + info->snd_seq,
> + &dp_ct_limit_genl_family, 0, cmd);
> +
> + if (!*ovs_reply_header) {
> + nlmsg_free(skb);
> + return ERR_PTR(-EMSGSIZE);
> + }
> + (*ovs_reply_header)->dp_ifindex = ovs_header->dp_ifindex;
> +
> + return skb;
> +}
> +
> +static int ovs_ct_limit_set_zone_limit(struct nlattr *nla_zone_limit,
> + struct ovs_ct_limit_info *info)
> +{
> + struct nlattr *nla;
> + int rem, err;
> +
> + nla_for_each_nested(nla, nla_zone_limit, rem) {
> + struct nlattr *attr[OVS_CT_ZONE_LIMIT_ATTR_MAX + 1];
> + struct ovs_ct_limit *ct_limit;
> +
> + if (nla_type(nla) != OVS_CT_ZONE_LIMIT_ATTR_SET_REQ)
> + return -EINVAL;
> +
> + err = nla_parse((struct nlattr **)&attr,
> + OVS_CT_ZONE_LIMIT_ATTR_MAX, nla_data(nla),
> + nla_len(nla), ct_zone_limit_policy, NULL);
> + if (err)
> + return err;
> +
> + if (attr[OVS_CT_ZONE_LIMIT_ATTR_DEFAULT_LIMIT]) {
> + u32 default_limit = nla_get_u32(
> + attr[OVS_CT_ZONE_LIMIT_ATTR_DEFAULT_LIMIT]);
> + ovs_lock();
> + info->default_limit = default_limit;
> + ovs_unlock();
> + } else {
> + if (!attr[OVS_CT_ZONE_LIMIT_ATTR_ZONE] ||
> + !attr[OVS_CT_ZONE_LIMIT_ATTR_LIMIT]) {
> + return -EINVAL;
> + }
> +
> + ct_limit = kmalloc(sizeof(*ct_limit), GFP_KERNEL);
> + if (!ct_limit)
> + return -ENOMEM;
> +
> + ct_limit->zone = nla_get_u16(
> + attr[OVS_CT_ZONE_LIMIT_ATTR_ZONE]);
> + ct_limit->limit = nla_get_u32(
> + attr[OVS_CT_ZONE_LIMIT_ATTR_LIMIT]);
> +
> + ovs_lock();
> + ct_limit_set(info, ct_limit);
> + ovs_unlock();
> + }
> + }
> + return 0;
> +}
> +
> +static int ovs_ct_limit_del_zone_limit(struct nlattr *nla_zone_limit,
> + struct ovs_ct_limit_info *info)
> +{
> + struct nlattr *nla;
> + int rem, err;
> +
> + nla_for_each_nested(nla, nla_zone_limit, rem) {
> + struct nlattr *attr[OVS_CT_ZONE_LIMIT_ATTR_MAX + 1];
> + u16 zone;
> +
> + if (nla_type(nla) != OVS_CT_ZONE_LIMIT_ATTR_DEL_REQ)
> + return -EINVAL;
> +
> + err = nla_parse((struct nlattr **)&attr,
> + OVS_CT_ZONE_LIMIT_ATTR_MAX, nla_data(nla),
> + nla_len(nla), ct_zone_limit_policy, NULL);
> + if (err)
> + return err;
> +
> + if (!attr[OVS_CT_ZONE_LIMIT_ATTR_ZONE])
> + return -EINVAL;
> +
> + zone = nla_get_u16(attr[OVS_CT_ZONE_LIMIT_ATTR_ZONE]);
> +
> + ovs_lock();
> + ct_limit_del(info, zone);
> + ovs_unlock();
> + }
> + return 0;
> +}
> +
> +static int ovs_ct_limit_get_default_limit(struct ovs_ct_limit_info *info,
> + struct sk_buff *reply)
> +{
> + int err;
> + struct nlattr *nla_nested;
> +
> + nla_nested = nla_nest_start(reply, OVS_CT_ZONE_LIMIT_ATTR_GET_RLY);
> +
> + err = nla_put_u32(reply, OVS_CT_ZONE_LIMIT_ATTR_DEFAULT_LIMIT,
> + info->default_limit);
> + if (err)
> + return err;
> +
> + nla_nest_end(reply, nla_nested);
> + return 0;
> +}
> +
> +static int ovs_ct_limit_get_zone_limit(struct net *net,
> + struct nlattr *nla_zone_limit,
> + struct ovs_ct_limit_info *info,
> + struct sk_buff *reply)
> +{
> + struct nlattr *nla, *nla_nested;
> + int rem, err;
> + u16 zone;
> + u32 limit, count, conncount_key[5];
> + struct nf_conntrack_zone ct_zone;
> +
> + nla_for_each_nested(nla, nla_zone_limit, rem) {
> + struct nlattr *attr[OVS_CT_ZONE_LIMIT_ATTR_MAX + 1];
> +
> + if (nla_type(nla) != OVS_CT_ZONE_LIMIT_ATTR_GET_REQ)
> + return -EINVAL;
> +
> + err = nla_parse((struct nlattr **)&attr,
> + OVS_CT_ZONE_LIMIT_ATTR_MAX, nla_data(nla),
> + nla_len(nla), ct_zone_limit_policy, NULL);
> + if (err)
> + return err;
> +
> + if (!attr[OVS_CT_ZONE_LIMIT_ATTR_ZONE])
> + return -EINVAL;
> +
> + zone = nla_get_u16(attr[OVS_CT_ZONE_LIMIT_ATTR_ZONE]);
> + nf_ct_zone_init(&ct_zone, zone, NF_CT_DEFAULT_ZONE_DIR, 0);
> + rcu_read_lock();
> + limit = ct_limit_get(info, zone);
> + rcu_read_unlock();
> +
> + conncount_key[0] = zone;
> + count = nf_conncount_count(net, info->data, conncount_key,
> + NULL, &ct_zone);
> +
> + nla_nested = nla_nest_start(reply,
> + OVS_CT_ZONE_LIMIT_ATTR_GET_RLY);
> + if (nla_put_u16(reply, OVS_CT_ZONE_LIMIT_ATTR_ZONE, zone) ||
> + nla_put_u32(reply, OVS_CT_ZONE_LIMIT_ATTR_LIMIT, limit) ||
> + nla_put_u32(reply, OVS_CT_ZONE_LIMIT_ATTR_COUNT, count))
> + return -EMSGSIZE;
> + nla_nest_end(reply, nla_nested);
> + }
> +
> + return 0;
> +}
> +
> +static int ovs_ct_limit_cmd_set(struct sk_buff *skb, struct genl_info *info)
> +{
> + struct nlattr **a = info->attrs;
> + struct sk_buff *reply;
> + struct ovs_header *ovs_reply_header;
> + struct ovs_net *ovs_net = net_generic(sock_net(skb->sk), ovs_net_id);
> + struct ovs_ct_limit_info *ct_limit_info = ovs_net->ct_limit_info;
> + int err;
> +
> + reply = ovs_ct_limit_cmd_reply_start(info, OVS_CT_LIMIT_CMD_SET,
> + &ovs_reply_header);
> + if (IS_ERR(reply))
> + return PTR_ERR(reply);
> +
> + if (!a[OVS_CT_LIMIT_ATTR_OPTION])
> + return -EINVAL;
> +
> + err = ovs_ct_limit_set_zone_limit(a[OVS_CT_LIMIT_ATTR_OPTION],
> + ct_limit_info);
> + if (err)
> + goto exit_err;
> +
> + genlmsg_end(reply, ovs_reply_header);
> + return genlmsg_reply(reply, info);
> +
> +exit_err:
> + nlmsg_free(reply);
> + return err;
> +}
> +
> +static int ovs_ct_limit_cmd_del(struct sk_buff *skb, struct genl_info *info)
> +{
> + struct nlattr **a = info->attrs;
> + struct sk_buff *reply;
> + struct ovs_header *ovs_reply_header;
> + struct ovs_net *ovs_net = net_generic(sock_net(skb->sk), ovs_net_id);
> + struct ovs_ct_limit_info *ct_limit_info = ovs_net->ct_limit_info;
> + int err;
> +
> + reply = ovs_ct_limit_cmd_reply_start(info, OVS_CT_LIMIT_CMD_DEL,
> + &ovs_reply_header);
> + if (IS_ERR(reply))
> + return PTR_ERR(reply);
> +
> + if (!a[OVS_CT_LIMIT_ATTR_OPTION])
> + return -EINVAL;
> +
> + err = ovs_ct_limit_del_zone_limit(a[OVS_CT_LIMIT_ATTR_OPTION],
> + ct_limit_info);
> + if (err)
> + goto exit_err;
> +
> + genlmsg_end(reply, ovs_reply_header);
> + return genlmsg_reply(reply, info);
> +
> +exit_err:
> + nlmsg_free(reply);
> + return err;
> +}
> +
> +static int ovs_ct_limit_cmd_get(struct sk_buff *skb, struct genl_info *info)
> +{
> + struct nlattr **a = info->attrs;
> + struct nlattr *nla_reply;
> + struct sk_buff *reply;
> + struct ovs_header *ovs_reply_header;
> + struct net *net = sock_net(skb->sk);
> + struct ovs_net *ovs_net = net_generic(net, ovs_net_id);
> + struct ovs_ct_limit_info *ct_limit_info = ovs_net->ct_limit_info;
> + int err;
> +
> + reply = ovs_ct_limit_cmd_reply_start(info, OVS_CT_LIMIT_CMD_GET,
> + &ovs_reply_header);
> + if (IS_ERR(reply))
> + return PTR_ERR(reply);
> +
> + nla_reply = nla_nest_start(reply, OVS_CT_LIMIT_ATTR_OPTION);
> +
> + err = ovs_ct_limit_get_default_limit(ct_limit_info, reply);
> + if (err)
> + goto exit_err;
> +
> + if (a[OVS_CT_LIMIT_ATTR_OPTION]) {
> + err = ovs_ct_limit_get_zone_limit(
> + net, a[OVS_CT_LIMIT_ATTR_OPTION], ct_limit_info,
> + reply);
> + if (err)
> + goto exit_err;
> + }
> +
> + nla_nest_end(reply, nla_reply);
> + genlmsg_end(reply, ovs_reply_header);
> + return genlmsg_reply(reply, info);
> +
> +exit_err:
> + nlmsg_free(reply);
> + return err;
> +}
> +
> +static struct genl_ops ct_limit_genl_ops[] = {
> + { .cmd = OVS_CT_LIMIT_CMD_SET,
> + .flags = GENL_ADMIN_PERM, /* Requires CAP_NET_ADMIN
> + * privilege. */
> + .policy = ct_limit_policy,
> + .doit = ovs_ct_limit_cmd_set,
> + },
> + { .cmd = OVS_CT_LIMIT_CMD_DEL,
> + .flags = GENL_ADMIN_PERM, /* Requires CAP_NET_ADMIN
> + * privilege. */
> + .policy = ct_limit_policy,
> + .doit = ovs_ct_limit_cmd_del,
> + },
> + { .cmd = OVS_CT_LIMIT_CMD_GET,
> + .flags = 0, /* OK for unprivileged users. */
> + .policy = ct_limit_policy,
> + .doit = ovs_ct_limit_cmd_get,
> + },
> +};
> +
> +static const struct genl_multicast_group ovs_ct_limit_multicast_group = {
> + .name = OVS_CT_LIMIT_MCGROUP,
> +};
> +
> +struct genl_family dp_ct_limit_genl_family __ro_after_init = {
> + .hdrsize = sizeof(struct ovs_header),
> + .name = OVS_CT_LIMIT_FAMILY,
> + .version = OVS_CT_LIMIT_VERSION,
> + .maxattr = OVS_CT_LIMIT_ATTR_MAX,
> + .netnsok = true,
> + .parallel_ops = true,
> + .ops = ct_limit_genl_ops,
> + .n_ops = ARRAY_SIZE(ct_limit_genl_ops),
> + .mcgrps = &ovs_ct_limit_multicast_group,
> + .n_mcgrps = 1,
> + .module = THIS_MODULE,
> +};
> +#endif
> +
> +int ovs_ct_init(struct net *net)
> {
> unsigned int n_bits = sizeof(struct ovs_key_ct_labels) * BITS_PER_BYTE;
> struct ovs_net *ovs_net = net_generic(net, ovs_net_id);
> @@ -1666,12 +2151,22 @@ void ovs_ct_init(struct net *net)
> } else {
> ovs_net->xt_label = true;
> }
> +
> +#if IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)
> + return ovs_ct_limit_init(net, ovs_net);
> +#else
> + return 0;
> +#endif
> }
>
> void ovs_ct_exit(struct net *net)
> {
> struct ovs_net *ovs_net = net_generic(net, ovs_net_id);
>
> +#if IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)
> + ovs_ct_limit_exit(net, ovs_net);
> +#endif
> +
> if (ovs_net->xt_label)
> nf_connlabels_put(net);
> }
> diff --git a/net/openvswitch/conntrack.h b/net/openvswitch/conntrack.h
> index 399dfdd2c4f9..900dadd70974 100644
> --- a/net/openvswitch/conntrack.h
> +++ b/net/openvswitch/conntrack.h
> @@ -17,10 +17,11 @@
> #include "flow.h"
>
> struct ovs_conntrack_info;
> +struct ovs_ct_limit_info;
> enum ovs_key_attr;
>
> #if IS_ENABLED(CONFIG_NF_CONNTRACK)
> -void ovs_ct_init(struct net *);
> +int ovs_ct_init(struct net *);
> void ovs_ct_exit(struct net *);
> bool ovs_ct_verify(struct net *, enum ovs_key_attr attr);
> int ovs_ct_copy_action(struct net *, const struct nlattr *,
> @@ -44,7 +45,7 @@ void ovs_ct_free_action(const struct nlattr *a);
> #else
> #include <linux/errno.h>
>
> -static inline void ovs_ct_init(struct net *net) { }
> +static inline int ovs_ct_init(struct net *net) { return 0; }
>
> static inline void ovs_ct_exit(struct net *net) { }
>
> @@ -104,4 +105,8 @@ static inline void ovs_ct_free_action(const struct nlattr *a) { }
>
> #define CT_SUPPORTED_MASK 0
> #endif /* CONFIG_NF_CONNTRACK */
> +
> +#if IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)
> +extern struct genl_family dp_ct_limit_genl_family;
> +#endif
> #endif /* ovs_conntrack.h */
> diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
> index 015e24e08909..a61818e94396 100644
> --- a/net/openvswitch/datapath.c
> +++ b/net/openvswitch/datapath.c
> @@ -2288,6 +2288,9 @@ static struct genl_family * const dp_genl_families[] = {
> &dp_flow_genl_family,
> &dp_packet_genl_family,
> &dp_meter_genl_family,
> +#if IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)
> + &dp_ct_limit_genl_family,
> +#endif
> };
>
> static void dp_unregister_genl(int n_families)
> @@ -2323,8 +2326,7 @@ static int __net_init ovs_init_net(struct net *net)
>
> INIT_LIST_HEAD(&ovs_net->dps);
> INIT_WORK(&ovs_net->dp_notify_work, ovs_dp_notify_wq);
> - ovs_ct_init(net);
> - return 0;
> + return ovs_ct_init(net);
> }
>
> static void __net_exit list_vports_from_net(struct net *net, struct net *dnet,
> @@ -2469,3 +2471,4 @@ MODULE_ALIAS_GENL_FAMILY(OVS_VPORT_FAMILY);
> MODULE_ALIAS_GENL_FAMILY(OVS_FLOW_FAMILY);
> MODULE_ALIAS_GENL_FAMILY(OVS_PACKET_FAMILY);
> MODULE_ALIAS_GENL_FAMILY(OVS_METER_FAMILY);
> +MODULE_ALIAS_GENL_FAMILY(OVS_CT_LIMIT_FAMILY);
> diff --git a/net/openvswitch/datapath.h b/net/openvswitch/datapath.h
> index 523d65526766..51bd4dcb6c8b 100644
> --- a/net/openvswitch/datapath.h
> +++ b/net/openvswitch/datapath.h
> @@ -144,6 +144,7 @@ struct dp_upcall_info {
> struct ovs_net {
> struct list_head dps;
> struct work_struct dp_notify_work;
> + struct ovs_ct_limit_info *ct_limit_info;
>
> /* Module reference for configuring conntrack. */
> bool xt_label;
^ permalink raw reply
* Re: [PATCH iproute2] utils: Do not reset family for default, any, all addresses
From: Stephen Hemminger @ 2018-04-17 0:01 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, whissi, Serhey Popovych
In-Reply-To: <20180413163633.1844-1-dsahern@gmail.com>
On Fri, 13 Apr 2018 09:36:33 -0700
David Ahern <dsahern@gmail.com> wrote:
> Thomas reported a change in behavior with respect to autodectecting
> address families. Specifically, 'ip ro add default via fe80::1'
> syntax was failing to treat fe80::1 as an IPv6 address as it did in
> prior releases. The root causes appears to be a change in family when
> the default keyword is parsed.
>
> 'default', 'any' and 'all' are relevant outside of AF_INET. Leave the
> family arg as is for these when setting addr.
>
> Fixes: 93fa12418dc6 ("utils: Always specify family and ->bytelen in get_prefix_1()")
> Reported-by: Thomas Deutschmann <whissi@gentoo.org>
> Signed-off-by: David Ahern <dsahern@gmail.com>
> Cc: Serhey Popovych <serhe.popovych@gmail.com>
Looks good, thanks for fixing.
Applied
^ permalink raw reply
* Re: [PATCH 08/10] net: ax88796: Make reset more robust on AX88796B
From: Michael Schmitz @ 2018-04-17 0:14 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, Linux/m68k, Michael Karcher, John Paul Adrian Glaubitz,
Michael Karcher
In-Reply-To: <20180416231223.GB23474@lunn.ch>
Hi Andrew,
On Tue, Apr 17, 2018 at 11:12 AM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Tue, Apr 17, 2018 at 10:04:43AM +1200, Michael Schmitz wrote:
>> From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
>>
>> The AX88796B as installed on the X-Surf-100 does not recognize a MII reset
>> request if the previous write to the MII control register also was a reset
>> request. So a dummy write to the control register makes the soft reset in
>> the PHY initialization code work.
>>
>> Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
>> ---
>> drivers/net/ethernet/8390/ax88796.c | 4 ++++
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/8390/ax88796.c b/drivers/net/ethernet/8390/ax88796.c
>> index 6af9aca..a2f9a09 100644
>> --- a/drivers/net/ethernet/8390/ax88796.c
>> +++ b/drivers/net/ethernet/8390/ax88796.c
>> @@ -374,6 +374,10 @@ static int ax_mii_probe(struct net_device *dev)
>> return -ENODEV;
>> }
>>
>> + /* write a non-reset pattern to the control register to
>> + * re-arm the reset request detection logic (needed on AX88796B)
>> + */
>> + phy_write(phy_dev, MII_BMCR, 0);
>
> This should really be fixed in the PHY driver, not the MAC.
OK - do you want this separate, or as part of this series? Might have
a few side effects on more commonly used hardware, perhaps?
Cheers,
Michael
>
> Andrew
^ permalink raw reply
* RE: [next-queue PATCH v7 01/10] igb: Fix not adding filter elements to the list
From: Brown, Aaron F @ 2018-04-17 0:52 UTC (permalink / raw)
To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
Cc: Gomes, Vinicius, Kirsher, Jeffrey T, netdev@vger.kernel.org,
Sanchez-Palencia, Jesus
In-Reply-To: <20180410174959.18757-2-vinicius.gomes@intel.com>
> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:17 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus <jesus.sanchez-palencia@intel.com>
> Subject: RE: [next-queue PATCH v7 01/10] igb: Fix not adding filter elements
> to the list
>
> > From: netdev-owner@vger.kernel.org [mailto:netdev-
> > owner@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> > <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> > Jesus <jesus.sanchez-palencia@intel.com>
> > Subject: [next-queue PATCH v7 01/10] igb: Fix not adding filter elements to
> > the list
> >
> > Because the order of the parameters passes to 'hlist_add_behind()' was
> > inverted, the 'parent' node was added "behind" the 'input', as input
> > is not in the list, this causes the 'input' node to be lost.
> >
> > Fixes: 0e71def25281 ("igb: add support of RX network flow classification")
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> > drivers/net/ethernet/intel/igb/igb_ethtool.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Resending with "Tested-by..." rather then "Tested by..." so that patchwork actually picks it up. What I get for signing off on the mails late Friday.
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [next-queue PATCH v7 02/10] igb: Fix queue selection on MAC filters on i210
From: Brown, Aaron F @ 2018-04-17 0:52 UTC (permalink / raw)
To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Sanchez-Palencia, Jesus
In-Reply-To: <20180410174959.18757-3-vinicius.gomes@intel.com>
> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:18 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> palencia@intel.com>
> Subject: RE: [Intel-wired-lan] [next-queue PATCH v7 02/10] igb: Fix queue
> selection on MAC filters on i210
>
> > From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
> > Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> > palencia@intel.com>
> > Subject: [Intel-wired-lan] [next-queue PATCH v7 02/10] igb: Fix queue
> > selection on MAC filters on i210
> >
> > On the RAH registers there are semantic differences on the meaning of
> > the "queue" parameter for traffic steering depending on the controller
> > model: there is the 82575 meaning, which "queue" means a RX Hardware
> > Queue, and the i350 meaning, where it is a reception pool.
> >
> > The previous behaviour was having no effect for i210 based controllers
> > because the QSEL bit of the RAH register wasn't being set.
> >
> > This patch separates the condition in discrete cases, so the different
> > handling is clearer.
> >
> > Fixes: 83c21335c876 ("igb: improve MAC filter handling")
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> > drivers/net/ethernet/intel/igb/igb_main.c | 13 +++++++++----
> > 1 file changed, 9 insertions(+), 4 deletions(-)
> >
>
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [next-queue PATCH v7 03/10] igb: Enable the hardware traffic class feature bit for igb models
From: Brown, Aaron F @ 2018-04-17 0:52 UTC (permalink / raw)
To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Sanchez-Palencia, Jesus
In-Reply-To: <20180410174959.18757-4-vinicius.gomes@intel.com>
> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:18 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> palencia@intel.com>
> Subject: RE: [Intel-wired-lan] [next-queue PATCH v7 03/10] igb: Enable the
> hardware traffic class feature bit for igb models
>
> > From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
> > Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> > palencia@intel.com>
> > Subject: [Intel-wired-lan] [next-queue PATCH v7 03/10] igb: Enable the
> > hardware traffic class feature bit for igb models
> >
> > This will allow functionality depending on the hardware being traffic
> > class aware to work. In particular the tc-flower offloading checks
> > verifies that this bit is set.
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> > drivers/net/ethernet/intel/igb/igb_main.c | 3 +++
> > 1 file changed, 3 insertions(+)
>
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* RE: [next-queue PATCH v7 04/10] igb: Add support for MAC address filters specifying source addresses
From: Brown, Aaron F @ 2018-04-17 0:53 UTC (permalink / raw)
To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
Cc: Gomes, Vinicius, Kirsher, Jeffrey T, netdev@vger.kernel.org,
Sanchez-Palencia, Jesus
In-Reply-To: <20180410174959.18757-5-vinicius.gomes@intel.com>
> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:19 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus <jesus.sanchez-palencia@intel.com>
> Subject: RE: [next-queue PATCH v7 04/10] igb: Add support for MAC address
> filters specifying source addresses
>
> > From: netdev-owner@vger.kernel.org [mailto:netdev-
> > owner@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> > <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> > Jesus <jesus.sanchez-palencia@intel.com>
> > Subject: [next-queue PATCH v7 04/10] igb: Add support for MAC address
> > filters specifying source addresses
> >
> > Makes it possible to direct packets to queues based on their source
> > address. Documents the expected usage of the 'flags' parameter.
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> > .../net/ethernet/intel/igb/e1000_defines.h | 1 +
> > drivers/net/ethernet/intel/igb/igb.h | 1 +
> > drivers/net/ethernet/intel/igb/igb_main.c | 40 ++++++++++++++++---
> > 3 files changed, 37 insertions(+), 5 deletions(-)
>
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [next-queue PATCH v7 05/10] igb: Add support for enabling queue steering in filters
From: Brown, Aaron F @ 2018-04-17 0:53 UTC (permalink / raw)
To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Sanchez-Palencia, Jesus
In-Reply-To: <20180410174959.18757-6-vinicius.gomes@intel.com>
> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:20 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> palencia@intel.com>
> Subject: RE: [Intel-wired-lan] [next-queue PATCH v7 05/10] igb: Add support
> for enabling queue steering in filters
>
> > From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
> > Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> > palencia@intel.com>
> > Subject: [Intel-wired-lan] [next-queue PATCH v7 05/10] igb: Add support
> for
> > enabling queue steering in filters
> >
> > On some igb models (82575 and i210) the MAC address filters can
> > control to which queue the packet will be assigned.
> >
> > This extends the 'state' with one more state to signify that queue
> > selection should be enabled for that filter.
> >
> > As 82575 parts are no longer easily obtained (and this was developed
> > against i210), only support for the i210 model is enabled.
> >
> > These functions are exported and will be used in the next patch.
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> > .../net/ethernet/intel/igb/e1000_defines.h | 1 +
> > drivers/net/ethernet/intel/igb/igb.h | 6 +++++
> > drivers/net/ethernet/intel/igb/igb_main.c | 26 +++++++++++++++++++
> > 3 files changed, 33 insertions(+)
>
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [next-queue PATCH v7 06/10] igb: Allow filters to be added for the local MAC address
From: Brown, Aaron F @ 2018-04-17 0:53 UTC (permalink / raw)
To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Sanchez-Palencia, Jesus
In-Reply-To: <20180410174959.18757-7-vinicius.gomes@intel.com>
> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:20 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> palencia@intel.com>
> Subject: RE: [Intel-wired-lan] [next-queue PATCH v7 06/10] igb: Allow filters
> to be added for the local MAC address
>
> > From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
> > Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> > palencia@intel.com>
> > Subject: [Intel-wired-lan] [next-queue PATCH v7 06/10] igb: Allow filters to
> > be added for the local MAC address
> >
> > Users expect that when adding a steering filter for the local MAC
> > address, that all the traffic directed to that address will go to some
> > queue.
> >
> > Currently, it's not possible to configure entries in the "in use"
> > state, which is the normal state of the local MAC address entry (it is
> > the default), this patch allows to override the steering configuration
> > of "in use" entries, if the filter to be added match the address and
> > address type (source or destination) of an existing entry.
> >
> > There is a bit of a special handling for entries referring to the
> > local MAC address, when they are removed, only the steering
> > configuration is reset.
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> > drivers/net/ethernet/intel/igb/igb_main.c | 40 ++++++++++++++++++++-
> --
> > 1 file changed, 36 insertions(+), 4 deletions(-)
>
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* RE: [next-queue PATCH v7 07/10] igb: Enable nfc filters to specify MAC addresses
From: Brown, Aaron F @ 2018-04-17 0:54 UTC (permalink / raw)
To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
Cc: Gomes, Vinicius, Kirsher, Jeffrey T, netdev@vger.kernel.org,
Sanchez-Palencia, Jesus
In-Reply-To: <20180410174959.18757-8-vinicius.gomes@intel.com>
> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:22 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus <jesus.sanchez-palencia@intel.com>
> Subject: RE: [next-queue PATCH v7 07/10] igb: Enable nfc filters to specify
> MAC addresses
>
> > From: netdev-owner@vger.kernel.org [mailto:netdev-
> > owner@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> > <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> > Jesus <jesus.sanchez-palencia@intel.com>
> > Subject: [next-queue PATCH v7 07/10] igb: Enable nfc filters to specify MAC
> > addresses
> >
> > This allows igb_add_filter()/igb_erase_filter() to work on filters
> > that include MAC addresses (both source and destination).
> >
> > For now, this only exposes the functionality, the next commit glues
> > ethtool into this. Later in this series, these APIs are used to allow
> > offloading of cls_flower filters.
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> > drivers/net/ethernet/intel/igb/igb.h | 4 +++
> > drivers/net/ethernet/intel/igb/igb_ethtool.c | 28
> ++++++++++++++++++++
> > 2 files changed, 32 insertions(+)
>
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* RE: [next-queue PATCH v7 08/10] igb: Add MAC address support for ethtool nftuple filters
From: Brown, Aaron F @ 2018-04-17 0:54 UTC (permalink / raw)
To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
Cc: Gomes, Vinicius, Kirsher, Jeffrey T, netdev@vger.kernel.org,
Sanchez-Palencia, Jesus
In-Reply-To: <20180410174959.18757-9-vinicius.gomes@intel.com>
> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:23 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus <jesus.sanchez-palencia@intel.com>
> Subject: RE: [next-queue PATCH v7 08/10] igb: Add MAC address support for
> ethtool nftuple filters
>
> > From: netdev-owner@vger.kernel.org [mailto:netdev-
> > owner@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> > <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> > Jesus <jesus.sanchez-palencia@intel.com>
> > Subject: [next-queue PATCH v7 08/10] igb: Add MAC address support for
> > ethtool nftuple filters
> >
> > This adds the capability of configuring the queue steering of arriving
> > packets based on their source and destination MAC addresses.
> >
> > Source address steering (i.e. driving traffic to a specific queue),
> > for the i210, does not work, but filtering does (i.e. accepting
> > traffic based on the source address). So, trying to add a filter
> > specifying only a source address will be an error.
> >
> > In practical terms this adds support for the following use cases,
> > characterized by these examples:
> >
> > $ ethtool -N eth0 flow-type ether dst aa:aa:aa:aa:aa:aa action 0
> > (this will direct packets with destination address "aa:aa:aa:aa:aa:aa"
> > to the RX queue 0)
> >
> > $ ethtool -N eth0 flow-type ether src 44:44:44:44:44:44 \
> > proto 0x22f0 action 3
> > (this will direct packets with source address "44:44:44:44:44:44" and
> > ethertype 0x22f0 to the RX queue 3)
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> > drivers/net/ethernet/intel/igb/igb_ethtool.c | 43 ++++++++++++++++++-
> -
> > 1 file changed, 39 insertions(+), 4 deletions(-)
> >
>
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [next-queue PATCH v7 09/10] igb: Add the skeletons for tc-flower offloading
From: Brown, Aaron F @ 2018-04-17 0:54 UTC (permalink / raw)
To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Sanchez-Palencia, Jesus
In-Reply-To: <20180410174959.18757-10-vinicius.gomes@intel.com>
> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:23 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> palencia@intel.com>
> Subject: RE: [Intel-wired-lan] [next-queue PATCH v7 09/10] igb: Add the
> skeletons for tc-flower offloading
>
> > From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
> > Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> > palencia@intel.com>
> > Subject: [Intel-wired-lan] [next-queue PATCH v7 09/10] igb: Add the
> > skeletons for tc-flower offloading
> >
> > This adds basic functions needed to implement offloading for filters
> > created by tc-flower.
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> > drivers/net/ethernet/intel/igb/igb_main.c | 66
> > +++++++++++++++++++++++
> > 1 file changed, 66 insertions(+)
> >
>
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* RE: [next-queue PATCH v7 10/10] igb: Add support for adding offloaded clsflower filters
From: Brown, Aaron F @ 2018-04-17 0:55 UTC (permalink / raw)
To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
Cc: Gomes, Vinicius, Kirsher, Jeffrey T, netdev@vger.kernel.org,
Sanchez-Palencia, Jesus
In-Reply-To: <20180410174959.18757-11-vinicius.gomes@intel.com>
> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:25 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus <jesus.sanchez-palencia@intel.com>
> Subject: RE: [next-queue PATCH v7 10/10] igb: Add support for adding
> offloaded clsflower filters
>
> > From: netdev-owner@vger.kernel.org [mailto:netdev-
> > owner@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> > <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> > Jesus <jesus.sanchez-palencia@intel.com>
> > Subject: [next-queue PATCH v7 10/10] igb: Add support for adding
> offloaded
> > clsflower filters
> >
> > This allows filters added by tc-flower and specifying MAC addresses,
> > Ethernet types, and the VLAN priority field, to be offloaded to the
> > controller.
> >
> > This reuses most of the infrastructure used by ethtool, but clsflower
> > filters are kept in a separated list, so they are invisible to
> > ethtool.
> >
> > To setup clsflower offloading:
> >
> > $ tc qdisc replace dev eth0 handle 100: parent root mqprio \
> > num_tc 3 map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \
> > queues 1@0 1@1 2@2 hw 0
> > (clsflower offloading depends on the netword driver to be configured
> > with multiple traffic classes, we use mqprio's 'num_tc' parameter to
> > set it to 3)
> >
> > $ tc qdisc add dev eth0 ingress
> >
> > Examples of filters:
> >
> > $ tc filter add dev eth0 parent ffff: flower \
> > dst_mac aa:aa:aa:aa:aa:aa \
> > hw_tc 2 skip_sw
> > (just a simple filter filtering for the destination MAC address and
> > steering that traffic to queue 2)
> >
> > $ tc filter add dev enp2s0 parent ffff: proto 0x22f0 flower \
> > src_mac cc:cc:cc:cc:cc:cc \
> > hw_tc 1 skip_sw
> > (as the i210 doesn't support steering traffic based on the source
> > address alone, we need to use another steering traffic, in this case
> > we are using the ethernet type (0x22f0) to steer traffic to queue 1)
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> > drivers/net/ethernet/intel/igb/igb.h | 2 +
> > drivers/net/ethernet/intel/igb/igb_main.c | 188
> > +++++++++++++++++++++-
> > 2 files changed, 188 insertions(+), 2 deletions(-)
>
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* RE: [next-queue PATCH] igb: Fix the transmission mode of queue 0 for Qav mode
From: Brown, Aaron F @ 2018-04-17 0:55 UTC (permalink / raw)
To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
Cc: Gomes, Vinicius, Kirsher, Jeffrey T, netdev@vger.kernel.org,
Sanchez-Palencia, Jesus, Guedes, Andre
In-Reply-To: <20180331000652.2855-1-vinicius.gomes@intel.com>
> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:28 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus <jesus.sanchez-palencia@intel.com>; Guedes, Andre
> <andre.guedes@intel.com>
> Subject: RE: [next-queue PATCH] igb: Fix the transmission mode of queue 0
> for Qav mode
>
> > From: netdev-owner@vger.kernel.org [mailto:netdev-
> > owner@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> > Sent: Friday, March 30, 2018 5:07 PM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> > <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> > Jesus <jesus.sanchez-palencia@intel.com>; Guedes, Andre
> > <andre.guedes@intel.com>
> > Subject: [next-queue PATCH] igb: Fix the transmission mode of queue 0 for
> > Qav mode
> >
> > When Qav mode is enabled, queue 0 should be kept on Stream
> Reservation
> > mode. From the i210 datasheet, section 8.12.19:
> >
> > "Note: Queue0 QueueMode must be set to 1b when TransmitMode is set
> to
> > Qav." ("QueueMode 1b" represents the Stream Reservation mode)
> >
> > The solution is to give queue 0 the all the credits it might need, so
> > it has priority over queue 1.
> >
> > A situation where this can happen is when cbs is "installed" only on
> > queue 1, leaving queue 0 alone. For example:
> >
> > $ tc qdisc replace dev enp2s0 handle 100: parent root mqprio num_tc 3 \
> > map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 queues 1@0 1@1 2@2 hw 0
> >
> > $ tc qdisc replace dev enp2s0 parent 100:2 cbs locredit -1470 \
> > hicredit 30 sendslope -980000 idleslope 20000 offload 1
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> > drivers/net/ethernet/intel/igb/igb_main.c | 17 ++++++++++++++++-
> > 1 file changed, 16 insertions(+), 1 deletion(-)
> >
>
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* Re: [PATCH 08/10] net: ax88796: Make reset more robust on AX88796B
From: Andrew Lunn @ 2018-04-17 1:32 UTC (permalink / raw)
To: Michael Schmitz
Cc: netdev, Linux/m68k, Michael Karcher, John Paul Adrian Glaubitz,
Michael Karcher
In-Reply-To: <CAOmrzkKoPwNRf5Nq=GN8ktP-9B5dNyGggFsrJ-Tr3D-z=Jj2rQ@mail.gmail.com>
> > This should really be fixed in the PHY driver, not the MAC.
>
> OK - do you want this separate, or as part of this series? Might have
> a few side effects on more commonly used hardware, perhaps?
Hi Michael
What PHY driver is used? In the driver you can implement a .soft_reset
function which first does the dummy write, and then uses
genphy_soft_reset() to do the actual reset.
Andrew
^ permalink raw reply
* [PATCH v2 3/8] net: ax88796: Do not free IRQ in ax_remove() (already freed in ax_close()).
From: Michael Schmitz @ 2018-04-17 2:08 UTC (permalink / raw)
To: netdev
Cc: andrew, linux-m68k, Michael.Karcher, John Paul Adrian Glaubitz,
Michael Karcher
In-Reply-To: <1523916285-6057-1-git-send-email-schmitzmic@gmail.com>
From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
This complements the fix in 82533ad9a1c that removed the free_irq
call in the error path of probe, to also not call free_irq when
remove is called to revert the effects of probe.
Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
---
drivers/net/ethernet/8390/ax88796.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/8390/ax88796.c b/drivers/net/ethernet/8390/ax88796.c
index 83e59ae..ecf104c 100644
--- a/drivers/net/ethernet/8390/ax88796.c
+++ b/drivers/net/ethernet/8390/ax88796.c
@@ -793,7 +793,6 @@ static int ax_remove(struct platform_device *pdev)
struct resource *mem;
unregister_netdev(dev);
- free_irq(dev->irq, dev);
iounmap(ei_local->mem);
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 0/8] New network driver for Amiga X-Surf 100 (m68k)
From: Michael Schmitz @ 2018-04-17 2:08 UTC (permalink / raw)
To: netdev; +Cc: andrew, linux-m68k, Michael.Karcher
In-Reply-To: <1523916285-6057-1-git-send-email-schmitzmic@gmail.com>
This patch series adds support for the Individual Computers X-Surf 100
network card for m68k Amiga, a network adapter based on the AX88796 chip set.
The driver was originally written for kernel version 3.19 by Michael Karcher
(see CC:), and adapted to 4.16 for submission to netdev by me. Questions
regarding motivation for some of the changes are probably best directed at
Michael Karcher.
The driver has been tested by Adrian <glaubitz@physik.fu-berlin.de> who will
send his Tested-by tag separately.
A few changes to the ax88796 driver were required:
- to read the MAC address, some setup of the ax99796 chip must be done,
- attach to the MII bus only on device open to allow module unloading,
- allow to supersede ax_block_input/ax_block_output by card-specific
optimized code,
- use an optional interrupt status callback to allow easier sharing of the
card interrupt,
- set IRQF_SHARED if platform IRQ resource is marked shareable,
Some additional cleanup:
- do not attempt to free IRQ in ax_remove (complements 82533ad9a1c),
- clear platform drvdata on probe fail and module remove.
Changes since v1:
Raised in review by Andrew Lunn:
- move MII code around to avoid need for forward declaration
- combine patches 2 and 7 to add cleanup in error path
The patch series, in order:
1/8 net: ax88796: Fix MAC address reading
2/8 net: ax88796: Attach MII bus only when open
3/8 net: ax88796: Do not free IRQ in ax_remove() (already freed in ax_close()).
4/8 net: ax88796: Add block_input/output hooks to ax_plat_data
5/8 net: ax88796: add interrupt status callback to platform data
6/8 net: ax88796: set IRQF_SHARED flag when IRQ resource is marked as shareable
7/8 net: ax88796: release platform device drvdata on probe error and module remove
8/8 net: New ax88796 platform driver for Amiga X-Surf 100 Zorro board (m68k)
drivers/net/ethernet/8390/Kconfig | 14 +-
drivers/net/ethernet/8390/Makefile | 1 +
drivers/net/ethernet/8390/ax88796.c | 228 +++++++++++--------
drivers/net/ethernet/8390/xsurf100.c | 411 ++++++++++++++++++++++++++++++++++
include/net/ax88796.h | 14 +-
5 files changed, 573 insertions(+), 95 deletions(-)
Cheers,
Michael
^ 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