* Re: [PATCH net-next] Revert "ipv4: make net_protocol const"
From: Stephen Hemminger @ 2017-08-28 21:18 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, bhumirks, davem
In-Reply-To: <1503951789-31836-1-git-send-email-dsahern@gmail.com>
On Mon, 28 Aug 2017 13:23:09 -0700
David Ahern <dsahern@gmail.com> wrote:
> This reverts commit aa8db499ea67cff1f5f049033810ffede2fe5ae4.
>
> Early demux structs can not be made const. Doing so results in:
> [ 84.967355] BUG: unable to handle kernel paging request at ffffffff81684b10
> [ 84.969272] IP: proc_configure_early_demux+0x1e/0x3d
> [ 84.970544] PGD 1a0a067
> [ 84.970546] P4D 1a0a067
> [ 84.971212] PUD 1a0b063
> [ 84.971733] PMD 80000000016001e1
>
> [ 84.972669] Oops: 0003 [#1] SMP
> [ 84.973065] Modules linked in: ip6table_filter ip6_tables veth vrf
> [ 84.973833] CPU: 0 PID: 955 Comm: sysctl Not tainted 4.13.0-rc6+ #22
> [ 84.974612] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
> [ 84.975855] task: ffff88003854ce00 task.stack: ffffc900005a4000
> [ 84.976580] RIP: 0010:proc_configure_early_demux+0x1e/0x3d
> [ 84.977253] RSP: 0018:ffffc900005a7dd0 EFLAGS: 00010246
> [ 84.977891] RAX: ffffffff81684b10 RBX: 0000000000000001 RCX: 0000000000000000
> [ 84.978759] RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000000000000
> [ 84.979628] RBP: ffffc900005a7dd0 R08: 0000000000000000 R09: 0000000000000000
> [ 84.980501] R10: 0000000000000001 R11: 0000000000000008 R12: 0000000000000001
> [ 84.981373] R13: ffffffffffffffea R14: ffffffff81a9b4c0 R15: 0000000000000002
> [ 84.982249] FS: 00007feb237b7700(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
> [ 84.983231] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 84.983941] CR2: ffffffff81684b10 CR3: 0000000038492000 CR4: 00000000000406f0
> [ 84.984817] Call Trace:
> [ 84.985133] proc_tcp_early_demux+0x29/0x30
>
> I think this is the second time such a patch has been reverted.
>
> Cc: Bhumika Goyal <bhumirks@gmail.com>
> Signed-off-by: David Ahern <dsahern@gmail.com>
This would have been caught at compile time if you tried setting inet_protos to const.
Start with that if you want to give it a try.
diff --git a/include/net/protocol.h b/include/net/protocol.h
index 65ba335b0e7e..373fa92d33ff 100644
--- a/include/net/protocol.h
+++ b/include/net/protocol.h
@@ -93,7 +93,7 @@ struct inet_protosw {
#define INET_PROTOSW_PERMANENT 0x02 /* Permanent protocols are unremovable. */
#define INET_PROTOSW_ICSK 0x04 /* Is this an inet_connection_sock? */
-extern struct net_protocol __rcu *inet_protos[MAX_INET_PROTOS];
+extern const struct net_protocol __rcu *inet_protos[MAX_INET_PROTOS];
extern const struct net_offload __rcu *inet_offloads[MAX_INET_PROTOS];
extern const struct net_offload __rcu *inet6_offloads[MAX_INET_PROTOS];
diff --git a/net/ipv4/protocol.c b/net/ipv4/protocol.c
index 32a691b7ce2c..4b7c0ec65251 100644
--- a/net/ipv4/protocol.c
+++ b/net/ipv4/protocol.c
@@ -28,7 +28,7 @@
#include <linux/spinlock.h>
#include <net/protocol.h>
-struct net_protocol __rcu *inet_protos[MAX_INET_PROTOS] __read_mostly;
+const struct net_protocol __rcu *inet_protos[MAX_INET_PROTOS] __read_mostly;
const struct net_offload __rcu *inet_offloads[MAX_INET_PROTOS] __read_mostly;
EXPORT_SYMBOL(inet_offloads);
net/ipv4/sysctl_net_ipv4.c: In function ‘proc_configure_early_demux’:
net/ipv4/sysctl_net_ipv4.c:310:9: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
ipprot = rcu_dereference(inet_protos[protocol]);
^ permalink raw reply related
* Re: Fwd: DA850-evm MAC Address is random
From: Tony Lindgren @ 2017-08-28 21:12 UTC (permalink / raw)
To: Adam Ford; +Cc: Grygorii Strashko, linux-omap, netdev, Sekhar Nori
In-Reply-To: <CAHCN7xLHEjda9DcVw5iHA9RaJ7UnyMVxf7e4e8NTEj9Op1JaBw@mail.gmail.com>
* Adam Ford <aford173@gmail.com> [170828 13:33]:
> On Mon, Aug 28, 2017 at 1:54 PM, Grygorii Strashko
> <grygorii.strashko@ti.com> wrote:
> > Cc: Sekhar
> >
> > On 08/28/2017 10:32 AM, Adam Ford wrote:
> >>
> >> The davinvi_emac MAC address seems to attempt a call to
> >> ti_cm_get_macid in cpsw-common.c but it returns the message
> >> 'davinci_emac davinci_emac.1: incompatible machine/device type for
> >> reading mac address ' and then generates a random MAC address.
> >>
> >> The function appears to lookup varions boards using
> >> 'of_machine_is_compaible' and supports dm8148, am33xx, am3517, dm816,
> >> am4372 and dra7. I don't see the ti,davinci-dm6467-emac which is
> >> what's shown in the da850 device tree.
> >>
> >> Is there a patch somewhere for supporting the da850-evm?
> >
> >
> > Not sure if MAC address can be read from Control module.
> > May be Sekhar can say more?
>
> My understanding is that the MAC address is programmed by Logic PD
> into the SPI flash. The Bootloader reads this from either SPI or its
> env variables. Looking at the partition info listed in the
> da850-evm.dts file, it appears as if they've reserved space for it.
> Unfortunately, I don't see any code that reads it out. I was hoping
> there might be a way to just pass cmdline parameter from the
> bootloader to the kernel to accept the MAC address.
>
> >
> >>
> >> If not, is there a way to pass the MAC address from U-Boot to the
> >> driver so it doesn't generate a random MAC?
> >
> >
> > "local-mac-address" dt porp
>
> The downside here, is that we'd have to have the Bootloader modify the
> device tree.
That piece of code exists somewhere in u-boot already. Note how
we are populating the mac address for USB Ethernet drivers in
u-boot and then the Ethernet driver code parses it. See commit
055d31de7158 ("ARM: omap3: beagleboard-xm: dt: Add ethernet to
the device tree") for some more information.
I think u-boot needs the ethernet alias for finding the interface.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH net-next] Revert "ipv4: make net_protocol const"
From: David Ahern @ 2017-08-28 21:03 UTC (permalink / raw)
To: David Miller; +Cc: netdev, bhumirks
In-Reply-To: <20170828.140133.2126200702424568912.davem@davemloft.net>
On 8/28/17 3:01 PM, David Miller wrote:
> From: David Ahern <dsahern@gmail.com>
> Date: Mon, 28 Aug 2017 13:23:09 -0700
>
>> This reverts commit aa8db499ea67cff1f5f049033810ffede2fe5ae4.
> ...
>> I think this is the second time such a patch has been reverted.
>
> Then please add a comment, it will help prevent this from happening
> again.
>
Was going to do that in both places after the revert. You want it as
part of this one?
^ permalink raw reply
* Re: [PATCH net-next] Revert "ipv4: make net_protocol const"
From: David Miller @ 2017-08-28 21:01 UTC (permalink / raw)
To: dsahern; +Cc: netdev, bhumirks
In-Reply-To: <1503951789-31836-1-git-send-email-dsahern@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Mon, 28 Aug 2017 13:23:09 -0700
> This reverts commit aa8db499ea67cff1f5f049033810ffede2fe5ae4.
...
> I think this is the second time such a patch has been reverted.
Then please add a comment, it will help prevent this from happening
again.
^ permalink raw reply
* RE: [RFC PATCH] net: limit maximum number of packets to mark with xmit_more
From: Keller, Jacob E @ 2017-08-28 20:56 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev@vger.kernel.org
In-Reply-To: <20170825153418.53864810@cakuba>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
> Behalf Of Jakub Kicinski
> Sent: Friday, August 25, 2017 12:34 PM
> To: Keller, Jacob E <jacob.e.keller@intel.com>
> Cc: netdev@vger.kernel.org
> Subject: Re: [RFC PATCH] net: limit maximum number of packets to mark with
> xmit_more
>
> On Fri, 25 Aug 2017 08:24:49 -0700, Jacob Keller wrote:
> > Under some circumstances, such as with many stacked devices, it is
> > possible that dev_hard_start_xmit will bundle many packets together, and
> > mark them all with xmit_more.
>
> Excuse my ignorance but what are those stacked devices? Could they
> perhaps be fixed somehow? My intuition was that long xmit_more
> sequences can only happen if NIC and/or BQL are back pressuring, and
> therefore we shouldn't be seeing a long xmit_more "train" arriving at
> an empty device ring...
a veth device connecting a VM to the host, then connected to a bridge, which is connected to a vlan interface connected to a bond, which is hooked in active-backup to a physical device.
Sorry if I don't really know the correct way to refer to these, I just think of them as devices stacked on top of each other.
During root cause investigation I found that we (the i40e driver) sometimes received up to 100 or more SKBs in a row with xmit_more set. We were incorrectly also using xmit_more as a hint for not marking packets to get writebacks, which caused significant throughput issues. Additionally there was concern that that many packets in a row without a tail bump would cause latency issues, so I thought maybe it was best to simply guarantee that the stack didn't send us too many packets marked with xmit more at once.
It seems based on discussion that it should be up to the driver to determine exactly how to handle the xmit_more hint and to determine when it actually isn't helpful or not, so I do not think this patch makes sense now.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH 1/6] ACPI: make device_attribute const
From: Rafael J. Wysocki @ 2017-08-28 20:56 UTC (permalink / raw)
To: Bhumika Goyal
Cc: julia.lawall, lenb, jbacik, jikos, benjamin.tissoires,
manish.chopra, rahul.verma, Dept-GELinuxNICDev, harish.patil,
cascardo, don, dvhart, andy, sre, linux-acpi, linux-kernel,
linux-block, nbd-general, linux-input, netdev,
platform-driver-x86, linux-pm
In-Reply-To: <1503315792-14837-2-git-send-email-bhumirks@gmail.com>
On Monday, August 21, 2017 1:43:07 PM CEST Bhumika Goyal wrote:
> Make these const as they are only passed as an argument to the function
> device_create_file and device_remove_file and the corresponding
> arguments are of type const.
> Done using Coccinelle
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
> ---
> drivers/acpi/battery.c | 2 +-
> drivers/acpi/sbs.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
> index 1cbb88d..13e7b56 100644
> --- a/drivers/acpi/battery.c
> +++ b/drivers/acpi/battery.c
> @@ -620,7 +620,7 @@ static ssize_t acpi_battery_alarm_store(struct device *dev,
> return count;
> }
>
> -static struct device_attribute alarm_attr = {
> +static const struct device_attribute alarm_attr = {
> .attr = {.name = "alarm", .mode = 0644},
> .show = acpi_battery_alarm_show,
> .store = acpi_battery_alarm_store,
> diff --git a/drivers/acpi/sbs.c b/drivers/acpi/sbs.c
> index a184637..a2428e9 100644
> --- a/drivers/acpi/sbs.c
> +++ b/drivers/acpi/sbs.c
> @@ -474,7 +474,7 @@ static ssize_t acpi_battery_alarm_store(struct device *dev,
> return count;
> }
>
> -static struct device_attribute alarm_attr = {
> +static const struct device_attribute alarm_attr = {
> .attr = {.name = "alarm", .mode = 0644},
> .show = acpi_battery_alarm_show,
> .store = acpi_battery_alarm_store,
>
Applied, thanks!
^ permalink raw reply
* [PATCH net-next] ipv6: Use rt6i_idev index for echo replies to a local address
From: David Ahern @ 2017-08-28 20:53 UTC (permalink / raw)
To: netdev, tariqt; +Cc: David Ahern
Tariq repored local pings to linklocal address is failing:
$ ifconfig ens8
ens8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 11.141.16.6 netmask 255.255.0.0 broadcast 11.141.255.255
inet6 fe80::7efe:90ff:fecb:7502 prefixlen 64 scopeid 0x20<link>
ether 7c:fe:90:cb:75:02 txqueuelen 1000 (Ethernet)
RX packets 12 bytes 1164 (1.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 30 bytes 2484 (2.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
$ /bin/ping6 -c 3 fe80::7efe:90ff:fecb:7502%ens8
PING fe80::7efe:90ff:fecb:7502%ens8(fe80::7efe:90ff:fecb:7502) 56 data bytes
--- fe80::7efe:90ff:fecb:7502%ens8 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2043ms
icmpv6_echo_reply needs to use the rt6i_idev dev index for local traffic
similar to how icmp6_send does. Convert the change for icmp6_send into a
helper that can be used in both places. Add the long over due
skb_rt6_info helper to convert dst on an skb to rt6_info similar to
skb_rtable for ipv4.
Fixes: 4832c30d5458 ("net: ipv6: put host and anycast routes on
device with address")
Reported-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: David Ahern <dsahern@gmail.com>
---
include/net/ip6_route.h | 10 ++++++++++
net/ipv6/icmp.c | 33 ++++++++++++++++++++-------------
2 files changed, 30 insertions(+), 13 deletions(-)
diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
index 882bc3c7ccde..ee96f402cb75 100644
--- a/include/net/ip6_route.h
+++ b/include/net/ip6_route.h
@@ -164,6 +164,16 @@ void rt6_mtu_change(struct net_device *dev, unsigned int mtu);
void rt6_remove_prefsrc(struct inet6_ifaddr *ifp);
void rt6_clean_tohost(struct net *net, struct in6_addr *gateway);
+static inline const struct rt6_info *skb_rt6_info(const struct sk_buff *skb)
+{
+ const struct dst_entry *dst = skb_dst(skb);
+ const struct rt6_info *rt6 = NULL;
+
+ if (dst)
+ rt6 = container_of(dst, struct rt6_info, dst);
+
+ return rt6;
+}
/*
* Store a destination cache entry in a socket
diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index dd7608cf1d72..c25b5954cfbb 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -399,6 +399,24 @@ static struct dst_entry *icmpv6_route_lookup(struct net *net,
return ERR_PTR(err);
}
+static int icmp6_iif(const struct sk_buff *skb)
+{
+ int iif = skb->dev->ifindex;
+
+ /* for local traffic to local address, skb dev is the loopback
+ * device. Check if there is a dst attached to the skb and if so
+ * get the real device index.
+ */
+ if (unlikely(iif == LOOPBACK_IFINDEX)) {
+ const struct rt6_info *rt6 = skb_rt6_info(skb);
+
+ if (rt6)
+ iif = rt6->rt6i_idev->dev->ifindex;
+ }
+
+ return iif;
+}
+
/*
* Send an ICMP message in response to a packet in error
*/
@@ -460,18 +478,7 @@ static void icmp6_send(struct sk_buff *skb, u8 type, u8 code, __u32 info,
*/
if (__ipv6_addr_needs_scope_id(addr_type)) {
- iif = skb->dev->ifindex;
-
- /* for local packets, get the real device index */
- if (iif == LOOPBACK_IFINDEX) {
- dst = skb_dst(skb);
- if (dst) {
- struct rt6_info *rt;
-
- rt = container_of(dst, struct rt6_info, dst);
- iif = rt->rt6i_idev->dev->ifindex;
- }
- }
+ iif = icmp6_iif(skb);
} else {
dst = skb_dst(skb);
iif = l3mdev_master_ifindex(dst ? dst->dev : skb->dev);
@@ -694,7 +701,7 @@ static void icmpv6_echo_reply(struct sk_buff *skb)
fl6.daddr = ipv6_hdr(skb)->saddr;
if (saddr)
fl6.saddr = *saddr;
- fl6.flowi6_oif = skb->dev->ifindex;
+ fl6.flowi6_oif = icmp6_iif(skb);
fl6.fl6_icmp_type = ICMPV6_ECHO_REPLY;
fl6.flowi6_mark = mark;
fl6.flowi6_uid = sock_net_uid(net, NULL);
--
2.1.4
^ permalink raw reply related
* RE: [RFC PATCH] net: limit maximum number of packets to mark with xmit_more
From: Keller, Jacob E @ 2017-08-28 20:46 UTC (permalink / raw)
To: Alexander Duyck, Stephen Hemminger
Cc: Waskiewicz Jr, Peter, netdev@vger.kernel.org
In-Reply-To: <CAKgT0UdC_8hTbc-p6cQPNy4=gbFnodZ3ZyKts329Yu8kiv-ZWw@mail.gmail.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
> Behalf Of Alexander Duyck
> Sent: Friday, August 25, 2017 3:34 PM
> To: Stephen Hemminger <stephen@networkplumber.org>
> Cc: Waskiewicz Jr, Peter <peter.waskiewicz.jr@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; netdev@vger.kernel.org
> Subject: Re: [RFC PATCH] net: limit maximum number of packets to mark with
> xmit_more
>
> On Fri, Aug 25, 2017 at 8:58 AM, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> > On Fri, 25 Aug 2017 15:36:22 +0000
> > "Waskiewicz Jr, Peter" <peter.waskiewicz.jr@intel.com> wrote:
> >
> >> On 8/25/17 11:25 AM, Jacob Keller wrote:
> >> > Under some circumstances, such as with many stacked devices, it is
> >> > possible that dev_hard_start_xmit will bundle many packets together, and
> >> > mark them all with xmit_more.
> >> >
> >> > Most drivers respond to xmit_more by skipping tail bumps on packet
> >> > rings, or similar behavior as long as xmit_more is set. This is
> >> > a performance win since it means drivers can avoid notifying hardware of
> >> > new packets repeat daily, and thus avoid wasting unnecessary PCIe or other
> >> > bandwidth.
> >> >
> >> > This use of xmit_more comes with a trade off because bundling too many
> >> > packets can increase latency of the Tx packets. To avoid this, we should
> >> > limit the maximum number of packets with xmit_more.
> >> >
> >> > Driver authors could modify their drivers to check for some determined
> >> > limit, but this requires all drivers to be modified in order to gain
> >> > advantage.
> >> >
> >> > Instead, add a sysctl "xmit_more_max" which can be used to configure the
> >> > maximum number of xmit_more skbs to send in a sequence. This ensures
> >> > that all drivers benefit, and allows system administrators the option to
> >> > tune the value to their environment.
> >> >
> >> > Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> >> > ---
> >> >
> >> > Stray thoughts and further questions....
> >> >
> >> > Is this the right approach? Did I miss any other places where we should
> >> > limit? Does the limit make sense? Should it instead be a per-device
> >> > tuning nob instead of a global? Is 32 a good default?
> >>
> >> I actually like the idea of a per-device knob. A xmit_more_max that's
> >> global in a system with 1GbE devices along with a 25/50GbE or more just
> >> doesn't make much sense to me. Or having heterogeneous vendor devices
> >> in the same system that have different HW behaviors could mask issues
> >> with latency.
> >>
> >> This seems like another incarnation of possible buffer-bloat if the max
> >> is too high...
> >>
> >> >
> >> > Documentation/sysctl/net.txt | 6 ++++++
> >> > include/linux/netdevice.h | 2 ++
> >> > net/core/dev.c | 10 +++++++++-
> >> > net/core/sysctl_net_core.c | 7 +++++++
> >> > 4 files changed, 24 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt
> >> > index b67044a2575f..3d995e8f4448 100644
> >> > --- a/Documentation/sysctl/net.txt
> >> > +++ b/Documentation/sysctl/net.txt
> >> > @@ -230,6 +230,12 @@ netdev_max_backlog
> >> > Maximum number of packets, queued on the INPUT side, when the
> interface
> >> > receives packets faster than kernel can process them.
> >> >
> >> > +xmit_more_max
> >> > +-------------
> >> > +
> >> > +Maximum number of packets in a row to mark with skb->xmit_more. A value
> of zero
> >> > +indicates no limit.
> >>
> >> What defines "packet?" MTU-sized packets, or payloads coming down from
> >> the stack (e.g. TSO's)?
> >
> > xmit_more is only a hint to the device. The device driver should ignore it unless
> > there are hardware advantages. The device driver is the place with HW specific
> > knowledge (like 4 Tx descriptors is equivalent to one PCI transaction on this
> device).
> >
> > Anything that pushes that optimization out to the user is only useful for
> benchmarks
> > and embedded devices.
>
> Actually I think I might have an idea what is going on here and I
> agree that this is probably something that needs to be fixed in the
> drivers. Especially since the problem isn't so much the skbs but
> descriptors in the descriptor ring.
>
> If I am not mistaken the issue is most drivers will honor the
> xmit_more unless the ring cannot enqueue another packet. The problem
> is if the clean-up is occurring on a different CPU than transmit we
> can cause the clean-up CPU/device DMA to go idle by not providing any
> notifications to the device that new packets are present. What we
> should probably do is look at adding another condition which is to
> force us to flush the packet if we have used over half of the
> descriptors in a given ring without notifying the device. Then that
> way we can be filling half while the device is processing the other
> half which should result in us operating smoothly.
>
> - Alex
Ok, and that definitely is driver specific, so I would be comfortable leaving that up to driver implementation. I'll look at creating a patch to do something like this for i40e.
Thanks,
Jake
^ permalink raw reply
* Re: Fwd: DA850-evm MAC Address is random
From: Adam Ford @ 2017-08-28 20:32 UTC (permalink / raw)
To: Grygorii Strashko; +Cc: linux-omap, netdev, Sekhar Nori
In-Reply-To: <b7aab9fc-17ba-077b-3ff3-28087e0b25bc@ti.com>
On Mon, Aug 28, 2017 at 1:54 PM, Grygorii Strashko
<grygorii.strashko@ti.com> wrote:
> Cc: Sekhar
>
> On 08/28/2017 10:32 AM, Adam Ford wrote:
>>
>> The davinvi_emac MAC address seems to attempt a call to
>> ti_cm_get_macid in cpsw-common.c but it returns the message
>> 'davinci_emac davinci_emac.1: incompatible machine/device type for
>> reading mac address ' and then generates a random MAC address.
>>
>> The function appears to lookup varions boards using
>> 'of_machine_is_compaible' and supports dm8148, am33xx, am3517, dm816,
>> am4372 and dra7. I don't see the ti,davinci-dm6467-emac which is
>> what's shown in the da850 device tree.
>>
>> Is there a patch somewhere for supporting the da850-evm?
>
>
> Not sure if MAC address can be read from Control module.
> May be Sekhar can say more?
My understanding is that the MAC address is programmed by Logic PD
into the SPI flash. The Bootloader reads this from either SPI or its
env variables. Looking at the partition info listed in the
da850-evm.dts file, it appears as if they've reserved space for it.
Unfortunately, I don't see any code that reads it out. I was hoping
there might be a way to just pass cmdline parameter from the
bootloader to the kernel to accept the MAC address.
>
>>
>> If not, is there a way to pass the MAC address from U-Boot to the
>> driver so it doesn't generate a random MAC?
>
>
> "local-mac-address" dt porp
The downside here, is that we'd have to have the Bootloader modify the
device tree.
>
> --
> regards,
> -grygorii
thanks
adam
^ permalink raw reply
* [PATCH net-next v1] amd-xgbe: Interrupt summary bits are h/w version dependent
From: Tom Lendacky @ 2017-08-28 20:29 UTC (permalink / raw)
To: netdev; +Cc: David Miller
There is a difference in the bit position of the normal interrupt summary
enable (NIE) and abnormal interrupt summary enable (AIE) between revisions
of the hardware. For older revisions the NIE and AIE bits are positions
16 and 15 respectively. For newer revisions the NIE and AIE bits are
positions 15 and 14. The effect in changing the bit position is that
newer hardware won't receive AIE interrupts in the current version of the
driver. Specifically, the driver uses this interrupt to collect
statistics on when a receive buffer unavailable event occurs and to
restart the driver/device when a fatal bus error occurs.
Update the driver to set the interrupt enable bit based on the reported
version of the hardware.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-common.h | 8 ++++++--
drivers/net/ethernet/amd/xgbe/xgbe-dev.c | 13 ++++++++++---
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-common.h b/drivers/net/ethernet/amd/xgbe/xgbe-common.h
index 9431330..7ea72ef 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-common.h
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-common.h
@@ -210,11 +210,15 @@
#define DMA_CH_CR_PBLX8_WIDTH 1
#define DMA_CH_CR_SPH_INDEX 24
#define DMA_CH_CR_SPH_WIDTH 1
-#define DMA_CH_IER_AIE_INDEX 15
+#define DMA_CH_IER_AIE20_INDEX 15
+#define DMA_CH_IER_AIE20_WIDTH 1
+#define DMA_CH_IER_AIE_INDEX 14
#define DMA_CH_IER_AIE_WIDTH 1
#define DMA_CH_IER_FBEE_INDEX 12
#define DMA_CH_IER_FBEE_WIDTH 1
-#define DMA_CH_IER_NIE_INDEX 16
+#define DMA_CH_IER_NIE20_INDEX 16
+#define DMA_CH_IER_NIE20_WIDTH 1
+#define DMA_CH_IER_NIE_INDEX 15
#define DMA_CH_IER_NIE_WIDTH 1
#define DMA_CH_IER_RBUE_INDEX 7
#define DMA_CH_IER_RBUE_WIDTH 1
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-dev.c b/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
index 671203d..e107e18 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
@@ -649,13 +649,15 @@ static void xgbe_config_flow_control(struct xgbe_prv_data *pdata)
static void xgbe_enable_dma_interrupts(struct xgbe_prv_data *pdata)
{
struct xgbe_channel *channel;
- unsigned int i;
+ unsigned int i, ver;
/* Set the interrupt mode if supported */
if (pdata->channel_irq_mode)
XGMAC_IOWRITE_BITS(pdata, DMA_MR, INTM,
pdata->channel_irq_mode);
+ ver = XGMAC_GET_BITS(pdata->hw_feat.version, MAC_VR, SNPSVER);
+
for (i = 0; i < pdata->channel_count; i++) {
channel = pdata->channel[i];
@@ -671,8 +673,13 @@ static void xgbe_enable_dma_interrupts(struct xgbe_prv_data *pdata)
* AIE - Abnormal Interrupt Summary Enable
* FBEE - Fatal Bus Error Enable
*/
- XGMAC_SET_BITS(channel->curr_ier, DMA_CH_IER, NIE, 1);
- XGMAC_SET_BITS(channel->curr_ier, DMA_CH_IER, AIE, 1);
+ if (ver < 0x21) {
+ XGMAC_SET_BITS(channel->curr_ier, DMA_CH_IER, NIE20, 1);
+ XGMAC_SET_BITS(channel->curr_ier, DMA_CH_IER, AIE20, 1);
+ } else {
+ XGMAC_SET_BITS(channel->curr_ier, DMA_CH_IER, NIE, 1);
+ XGMAC_SET_BITS(channel->curr_ier, DMA_CH_IER, AIE, 1);
+ }
XGMAC_SET_BITS(channel->curr_ier, DMA_CH_IER, FBEE, 1);
if (channel->tx_ring) {
^ permalink raw reply related
* [PATCH net-next] Revert "ipv4: make net_protocol const"
From: David Ahern @ 2017-08-28 20:23 UTC (permalink / raw)
To: netdev, bhumirks, davem; +Cc: David Ahern
This reverts commit aa8db499ea67cff1f5f049033810ffede2fe5ae4.
Early demux structs can not be made const. Doing so results in:
[ 84.967355] BUG: unable to handle kernel paging request at ffffffff81684b10
[ 84.969272] IP: proc_configure_early_demux+0x1e/0x3d
[ 84.970544] PGD 1a0a067
[ 84.970546] P4D 1a0a067
[ 84.971212] PUD 1a0b063
[ 84.971733] PMD 80000000016001e1
[ 84.972669] Oops: 0003 [#1] SMP
[ 84.973065] Modules linked in: ip6table_filter ip6_tables veth vrf
[ 84.973833] CPU: 0 PID: 955 Comm: sysctl Not tainted 4.13.0-rc6+ #22
[ 84.974612] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 84.975855] task: ffff88003854ce00 task.stack: ffffc900005a4000
[ 84.976580] RIP: 0010:proc_configure_early_demux+0x1e/0x3d
[ 84.977253] RSP: 0018:ffffc900005a7dd0 EFLAGS: 00010246
[ 84.977891] RAX: ffffffff81684b10 RBX: 0000000000000001 RCX: 0000000000000000
[ 84.978759] RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000000000000
[ 84.979628] RBP: ffffc900005a7dd0 R08: 0000000000000000 R09: 0000000000000000
[ 84.980501] R10: 0000000000000001 R11: 0000000000000008 R12: 0000000000000001
[ 84.981373] R13: ffffffffffffffea R14: ffffffff81a9b4c0 R15: 0000000000000002
[ 84.982249] FS: 00007feb237b7700(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
[ 84.983231] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 84.983941] CR2: ffffffff81684b10 CR3: 0000000038492000 CR4: 00000000000406f0
[ 84.984817] Call Trace:
[ 84.985133] proc_tcp_early_demux+0x29/0x30
I think this is the second time such a patch has been reverted.
Cc: Bhumika Goyal <bhumirks@gmail.com>
Signed-off-by: David Ahern <dsahern@gmail.com>
---
Bhumika: How are you testing these constify changes? In this case a simple
sysctl -w net.ipv4.tcp_early_demux=1 would have shown the problem
net/ipv4/af_inet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 19aee073ba29..d678820e4306 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1596,7 +1596,7 @@ static const struct net_protocol igmp_protocol = {
};
#endif
-static const struct net_protocol tcp_protocol = {
+static struct net_protocol tcp_protocol = {
.early_demux = tcp_v4_early_demux,
.early_demux_handler = tcp_v4_early_demux,
.handler = tcp_v4_rcv,
@@ -1606,7 +1606,7 @@ static const struct net_protocol tcp_protocol = {
.icmp_strict_tag_validation = 1,
};
-static const struct net_protocol udp_protocol = {
+static struct net_protocol udp_protocol = {
.early_demux = udp_v4_early_demux,
.early_demux_handler = udp_v4_early_demux,
.handler = udp_rcv,
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net-next v2 01/10] net: dsa: add debugfs interface
From: Andrew Lunn @ 2017-08-28 20:19 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, David S. Miller, Florian Fainelli,
Egil Hjelmeland, John Crispin, Woojung Huh, Sean Wang,
Nikita Yushchenko, Chris Healy
In-Reply-To: <20170828191748.19492-2-vivien.didelot@savoirfairelinux.com>
On Mon, Aug 28, 2017 at 03:17:39PM -0400, Vivien Didelot wrote:
> This commit adds a DEBUG_FS dependent DSA core file creating a generic
> debug filesystem interface for the DSA switch devices.
>
> The interface can be mounted with:
>
> # mount -t debugfs none /sys/kernel/debug
>
> The dsa directory contains one directory per switch chip:
>
> # cd /sys/kernel/debug/dsa/
> # ls
> switch0 switch1 switch2
>
> Each chip directory contains one directory per port:
>
> # ls -l switch0/
> drwxr-xr-x 2 root root 0 Jan 1 00:00 port0
> drwxr-xr-x 2 root root 0 Jan 1 00:00 port1
> drwxr-xr-x 2 root root 0 Jan 1 00:00 port2
> drwxr-xr-x 2 root root 0 Jan 1 00:00 port5
> drwxr-xr-x 2 root root 0 Jan 1 00:00 port6
>
> Future patches will add entry files to these directories.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 03/10] net: dsa: debugfs: add tag_protocol
From: Andrew Lunn @ 2017-08-28 20:16 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, David S. Miller, Florian Fainelli,
Egil Hjelmeland, John Crispin, Woojung Huh, Sean Wang,
Nikita Yushchenko, Chris Healy
In-Reply-To: <20170828191748.19492-4-vivien.didelot@savoirfairelinux.com>
On Mon, Aug 28, 2017 at 03:17:41PM -0400, Vivien Didelot wrote:
> Add a debug filesystem "tag_protocol" entry to query the switch tagging
> protocol through the .get_tag_protocol operation.
>
> # cat switch1/tag_protocol
> EDSA
>
> To ease maintenance of tag protocols, add a dsa_tag_protocol_name helper
> to the public API which to convert a tag protocol enum to a string.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 00/10] net: dsa: add generic debugfs interface
From: Andrew Lunn @ 2017-08-28 20:08 UTC (permalink / raw)
To: Jiri Pirko
Cc: Vivien Didelot, netdev, linux-kernel, kernel, David S. Miller,
Florian Fainelli, Egil Hjelmeland, John Crispin, Woojung Huh,
Sean Wang, Nikita Yushchenko, Chris Healy, mlxsw
In-Reply-To: <20170828195332.GB1950@nanopsycho.orion>
> I see this overlaps a lot with DPIPE. Why won't you use that to expose
> your hw state?
We took a look at dpipe and i talked to you about using it for this
sort of thing at netconf/netdev. But dpipe has issues displaying the
sort of information we have. I never figured out how to do two
dimensional tables. The output of the dpipe command is pretty
unreadable. A lot of the information being dumped here is not about
the data pipe, etc.
There is a lot of pushback on debugfs for individual drivers. As i
said recently to somebody, debugfs is a bit of a wild west. When
designing this code, we thought about that. This debugfs is not at the
driver level. It is at the DSA level. All DSA drivers will benefit
from this code, and all DSA drivers will get the same information
exposed in debugfs. It is generic, well defined and structured, with
respect to DSA.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 01/10] net: dsa: add debugfs interface
From: Jiri Pirko @ 2017-08-28 20:05 UTC (permalink / raw)
To: Florian Fainelli
Cc: Vivien Didelot, netdev, linux-kernel, kernel, David S. Miller,
Andrew Lunn, Egil Hjelmeland, John Crispin, Woojung Huh,
Sean Wang, Nikita Yushchenko, Chris Healy
In-Reply-To: <b642a93c-1f63-522d-e9f2-c266b809623a@gmail.com>
Mon, Aug 28, 2017 at 09:58:12PM CEST, f.fainelli@gmail.com wrote:
>On 08/28/2017 12:50 PM, Jiri Pirko wrote:
>> Mon, Aug 28, 2017 at 09:17:39PM CEST, vivien.didelot@savoirfairelinux.com wrote:
>>> This commit adds a DEBUG_FS dependent DSA core file creating a generic
>>> debug filesystem interface for the DSA switch devices.
>>>
>>> The interface can be mounted with:
>>>
>>> # mount -t debugfs none /sys/kernel/debug
>>>
>>> The dsa directory contains one directory per switch chip:
>>>
>>> # cd /sys/kernel/debug/dsa/
>>> # ls
>>> switch0 switch1 switch2
>>>
>>> Each chip directory contains one directory per port:
>>>
>>> # ls -l switch0/
>>> drwxr-xr-x 2 root root 0 Jan 1 00:00 port0
>>> drwxr-xr-x 2 root root 0 Jan 1 00:00 port1
>>> drwxr-xr-x 2 root root 0 Jan 1 00:00 port2
>>> drwxr-xr-x 2 root root 0 Jan 1 00:00 port5
>>> drwxr-xr-x 2 root root 0 Jan 1 00:00 port6
>>>
>>> Future patches will add entry files to these directories.
>>>
>>> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
>>
>> Oh no, no debugfs please!
>>
>> What do you need to expose? I'm sure we can find out some generic, well
>> defined and reusable way.
>
>We have no CPU or DSA (cross switches) net_device reprensentors because
>those would be two ends of the same pipe so it would be both confusing
So? That is certainly not an argument for debugfs. Just have all ports
as devlink port, and you can introduce special new kind of port for cpu
port. Note that devlink port does not have to have netdev association.
>and a duplication. For a CPU interface, one side goes to the switch, the
>other one is the master net_device (normal Ethernet MAC). For a DSA
>interface, one interface is on one switch, and the other is on the other
>switch.
>
>If you look at the patch series it's pretty obvious what is being exposed :)
Sure. But lets use existing interfaces and extend them if needed. Please
don't use some made-up debugfs mess. That is never the correct answer :/
^ permalink raw reply
* Re: [PATCH net-next v2 01/10] net: dsa: add debugfs interface
From: Florian Fainelli @ 2017-08-28 19:58 UTC (permalink / raw)
To: Jiri Pirko, Vivien Didelot
Cc: netdev, linux-kernel, kernel, David S. Miller, Andrew Lunn,
Egil Hjelmeland, John Crispin, Woojung Huh, Sean Wang,
Nikita Yushchenko, Chris Healy
In-Reply-To: <20170828195039.GA1950@nanopsycho.orion>
On 08/28/2017 12:50 PM, Jiri Pirko wrote:
> Mon, Aug 28, 2017 at 09:17:39PM CEST, vivien.didelot@savoirfairelinux.com wrote:
>> This commit adds a DEBUG_FS dependent DSA core file creating a generic
>> debug filesystem interface for the DSA switch devices.
>>
>> The interface can be mounted with:
>>
>> # mount -t debugfs none /sys/kernel/debug
>>
>> The dsa directory contains one directory per switch chip:
>>
>> # cd /sys/kernel/debug/dsa/
>> # ls
>> switch0 switch1 switch2
>>
>> Each chip directory contains one directory per port:
>>
>> # ls -l switch0/
>> drwxr-xr-x 2 root root 0 Jan 1 00:00 port0
>> drwxr-xr-x 2 root root 0 Jan 1 00:00 port1
>> drwxr-xr-x 2 root root 0 Jan 1 00:00 port2
>> drwxr-xr-x 2 root root 0 Jan 1 00:00 port5
>> drwxr-xr-x 2 root root 0 Jan 1 00:00 port6
>>
>> Future patches will add entry files to these directories.
>>
>> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
>
> Oh no, no debugfs please!
>
> What do you need to expose? I'm sure we can find out some generic, well
> defined and reusable way.
We have no CPU or DSA (cross switches) net_device reprensentors because
those would be two ends of the same pipe so it would be both confusing
and a duplication. For a CPU interface, one side goes to the switch, the
other one is the master net_device (normal Ethernet MAC). For a DSA
interface, one interface is on one switch, and the other is on the other
switch.
If you look at the patch series it's pretty obvious what is being exposed :)
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v2 00/10] net: dsa: add generic debugfs interface
From: Jiri Pirko @ 2017-08-28 19:53 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Egil Hjelmeland, John Crispin, Woojung Huh,
Sean Wang, Nikita Yushchenko, Chris Healy, mlxsw
In-Reply-To: <20170828191748.19492-1-vivien.didelot@savoirfairelinux.com>
Mon, Aug 28, 2017 at 09:17:38PM CEST, vivien.didelot@savoirfairelinux.com wrote:
>This patch series adds a generic debugfs interface for the DSA
>framework, so that all switch devices benefit from it, e.g. Marvell,
>Broadcom, Microchip or any other DSA driver.
>
>This is really convenient for debugging, especially CPU ports and DSA
>links which are not exposed to userspace as net device. This interface
>is currently the only way to easily inspect the hardware for such ports.
>
>With the patch series, any switch device user is able to query the
>hardware for the supported tagging protocol, the ports stats and
>registers, as well as their FDB, MDB and VLAN entries.
I see this overlaps a lot with DPIPE. Why won't you use that to expose
your hw state?
^ permalink raw reply
* Re: [PATCH net-next v2 01/10] net: dsa: add debugfs interface
From: Jiri Pirko @ 2017-08-28 19:50 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Egil Hjelmeland, John Crispin, Woojung Huh,
Sean Wang, Nikita Yushchenko, Chris Healy
In-Reply-To: <20170828191748.19492-2-vivien.didelot@savoirfairelinux.com>
Mon, Aug 28, 2017 at 09:17:39PM CEST, vivien.didelot@savoirfairelinux.com wrote:
>This commit adds a DEBUG_FS dependent DSA core file creating a generic
>debug filesystem interface for the DSA switch devices.
>
>The interface can be mounted with:
>
> # mount -t debugfs none /sys/kernel/debug
>
>The dsa directory contains one directory per switch chip:
>
> # cd /sys/kernel/debug/dsa/
> # ls
> switch0 switch1 switch2
>
>Each chip directory contains one directory per port:
>
> # ls -l switch0/
> drwxr-xr-x 2 root root 0 Jan 1 00:00 port0
> drwxr-xr-x 2 root root 0 Jan 1 00:00 port1
> drwxr-xr-x 2 root root 0 Jan 1 00:00 port2
> drwxr-xr-x 2 root root 0 Jan 1 00:00 port5
> drwxr-xr-x 2 root root 0 Jan 1 00:00 port6
>
>Future patches will add entry files to these directories.
>
>Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Oh no, no debugfs please!
What do you need to expose? I'm sure we can find out some generic, well
defined and reusable way.
^ permalink raw reply
* [PATCH net-next 4/4] nsh: add GSO support
From: Jiri Benc @ 2017-08-28 19:43 UTC (permalink / raw)
To: netdev; +Cc: Yi Yang, Eric Garver, Jan Scheurich, Ben Pfaff
In-Reply-To: <cover.1503948295.git.jbenc@redhat.com>
Add a new nsh/ directory. It currently holds only GSO functions but more
will come: in particular, code shared by openvswitch and tc to manipulate
NSH headers.
For now, assume there's no hardware support for NSH segmentation. We can
always introduce netdev->nsh_features later.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
net/Kconfig | 1 +
net/Makefile | 1 +
net/nsh/Kconfig | 9 ++++++
net/nsh/Makefile | 1 +
net/nsh/nsh.c | 91 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 103 insertions(+)
create mode 100644 net/nsh/Kconfig
create mode 100644 net/nsh/Makefile
create mode 100644 net/nsh/nsh.c
diff --git a/net/Kconfig b/net/Kconfig
index 7d57ef34b79c..45def78912ce 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -235,6 +235,7 @@ source "net/openvswitch/Kconfig"
source "net/vmw_vsock/Kconfig"
source "net/netlink/Kconfig"
source "net/mpls/Kconfig"
+source "net/nsh/Kconfig"
source "net/hsr/Kconfig"
source "net/switchdev/Kconfig"
source "net/l3mdev/Kconfig"
diff --git a/net/Makefile b/net/Makefile
index bed80fa398b7..e03c3888179f 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_NET_IFE) += ife/
obj-$(CONFIG_OPENVSWITCH) += openvswitch/
obj-$(CONFIG_VSOCKETS) += vmw_vsock/
obj-$(CONFIG_MPLS) += mpls/
+obj-$(CONFIG_NET_NSH) += nsh/
obj-$(CONFIG_HSR) += hsr/
ifneq ($(CONFIG_NET_SWITCHDEV),)
obj-y += switchdev/
diff --git a/net/nsh/Kconfig b/net/nsh/Kconfig
new file mode 100644
index 000000000000..bafc3dd60c2c
--- /dev/null
+++ b/net/nsh/Kconfig
@@ -0,0 +1,9 @@
+menuconfig NET_NSH
+ tristate "Network Service Header (NSH) protocol"
+ default n
+ ---help---
+ Network Service Header is an implementation of Service Function
+ Chaining (RFC 7665). The current implementation in Linux supports
+ only MD type 1 and only with the openvswitch module.
+
+ If unsure, say N.
diff --git a/net/nsh/Makefile b/net/nsh/Makefile
new file mode 100644
index 000000000000..c93c787385ca
--- /dev/null
+++ b/net/nsh/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_NET_NSH) += nsh.o
diff --git a/net/nsh/nsh.c b/net/nsh/nsh.c
new file mode 100644
index 000000000000..58fb827439a8
--- /dev/null
+++ b/net/nsh/nsh.c
@@ -0,0 +1,91 @@
+/*
+ * Network Service Header
+ *
+ * Copyright (c) 2017 Red Hat, Inc. -- Jiri Benc <jbenc@redhat.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/netdevice.h>
+#include <linux/skbuff.h>
+#include <net/nsh.h>
+#include <net/tun_proto.h>
+
+static struct sk_buff *nsh_gso_segment(struct sk_buff *skb,
+ netdev_features_t features)
+{
+ struct sk_buff *segs = ERR_PTR(-EINVAL);
+ unsigned int nsh_len, mac_len;
+ __be16 proto;
+ int nhoff;
+
+ skb_reset_network_header(skb);
+
+ nhoff = skb->network_header - skb->mac_header;
+ mac_len = skb->mac_len;
+
+ if (unlikely(!pskb_may_pull(skb, NSH_BASE_HDR_LEN)))
+ goto out;
+ nsh_len = nsh_hdr_len(nsh_hdr(skb));
+ if (unlikely(!pskb_may_pull(skb, nsh_len)))
+ goto out;
+
+ proto = tun_p_to_eth_p(nsh_hdr(skb)->np);
+ if (!proto)
+ goto out;
+
+ __skb_pull(skb, nsh_len);
+
+ skb_reset_mac_header(skb);
+ skb_reset_mac_len(skb);
+ skb->protocol = proto;
+
+ features &= NETIF_F_SG;
+ segs = skb_mac_gso_segment(skb, features);
+ if (IS_ERR_OR_NULL(segs)) {
+ skb_gso_error_unwind(skb, htons(ETH_P_NSH), nsh_len,
+ skb->network_header - nhoff,
+ mac_len);
+ goto out;
+ }
+
+ for (skb = segs; skb; skb = skb->next) {
+ skb->protocol = htons(ETH_P_NSH);
+ __skb_push(skb, nsh_len);
+ skb_set_mac_header(skb, -nhoff);
+ skb->network_header = skb->mac_header + mac_len;
+ skb->mac_len = mac_len;
+ }
+
+out:
+ return segs;
+}
+
+static struct packet_offload nsh_packet_offload __read_mostly = {
+ .type = htons(ETH_P_NSH),
+ .priority = 15,
+ .callbacks = {
+ .gso_segment = nsh_gso_segment,
+ },
+};
+
+static int __init nsh_init_module(void)
+{
+ dev_add_offload(&nsh_packet_offload);
+ return 0;
+}
+
+static void __exit nsh_cleanup_module(void)
+{
+ dev_remove_offload(&nsh_packet_offload);
+}
+
+module_init(nsh_init_module);
+module_exit(nsh_cleanup_module);
+
+MODULE_AUTHOR("Jiri Benc <jbenc@redhat.com>");
+MODULE_DESCRIPTION("NSH protocol");
+MODULE_LICENSE("GPL v2");
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 3/4] net: add NSH header structures and helpers
From: Jiri Benc @ 2017-08-28 19:43 UTC (permalink / raw)
To: netdev; +Cc: Yi Yang, Eric Garver, Jan Scheurich, Ben Pfaff
In-Reply-To: <cover.1503948295.git.jbenc@redhat.com>
From: Yi Yang <yi.y.yang@intel.com>
NSH (Network Service Header)[1] is a new protocol for service
function chaining, it can be handled as a L3 protocol like
IPv4 and IPv6, Eth + NSH + Inner packet or VxLAN-gpe + NSH +
Inner packet are two typical use cases.
This patch adds NSH header structures and helpers for NSH GSO
support and Open vSwitch NSH support.
[1] https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/
[Jiri: added nsh_hdr() helper and renamed the header struct to "struct
nshhdr" to match the usual pattern. Removed packet type defines, these are
now shared with VXLAN-GPE.]
Signed-off-by: Yi Yang <yi.y.yang@intel.com>
Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
include/net/nsh.h | 307 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 307 insertions(+)
create mode 100644 include/net/nsh.h
diff --git a/include/net/nsh.h b/include/net/nsh.h
new file mode 100644
index 000000000000..a1eaea20be96
--- /dev/null
+++ b/include/net/nsh.h
@@ -0,0 +1,307 @@
+#ifndef __NET_NSH_H
+#define __NET_NSH_H 1
+
+#include <linux/skbuff.h>
+
+/*
+ * Network Service Header:
+ * 0 1 2 3
+ * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Service Path Identifier (SPI) | Service Index |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | |
+ * ~ Mandatory/Optional Context Headers ~
+ * | |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *
+ * Version: The version field is used to ensure backward compatibility
+ * going forward with future NSH specification updates. It MUST be set
+ * to 0x0 by the sender, in this first revision of NSH. Given the
+ * widespread implementation of existing hardware that uses the first
+ * nibble after an MPLS label stack for ECMP decision processing, this
+ * document reserves version 01b and this value MUST NOT be used in
+ * future versions of the protocol. Please see [RFC7325] for further
+ * discussion of MPLS-related forwarding requirements.
+ *
+ * O bit: Setting this bit indicates an Operations, Administration, and
+ * Maintenance (OAM) packet. The actual format and processing of SFC
+ * OAM packets is outside the scope of this specification (see for
+ * example [I-D.ietf-sfc-oam-framework] for one approach).
+ *
+ * The O bit MUST be set for OAM packets and MUST NOT be set for non-OAM
+ * packets. The O bit MUST NOT be modified along the SFP.
+ *
+ * SF/SFF/SFC Proxy/Classifier implementations that do not support SFC
+ * OAM procedures SHOULD discard packets with O bit set, but MAY support
+ * a configurable parameter to enable forwarding received SFC OAM
+ * packets unmodified to the next element in the chain. Forwarding OAM
+ * packets unmodified by SFC elements that do not support SFC OAM
+ * procedures may be acceptable for a subset of OAM functions, but can
+ * result in unexpected outcomes for others, thus it is recommended to
+ * analyze the impact of forwarding an OAM packet for all OAM functions
+ * prior to enabling this behavior. The configurable parameter MUST be
+ * disabled by default.
+ *
+ * TTL: Indicates the maximum SFF hops for an SFP. This field is used
+ * for service plane loop detection. The initial TTL value SHOULD be
+ * configurable via the control plane; the configured initial value can
+ * be specific to one or more SFPs. If no initial value is explicitly
+ * provided, the default initial TTL value of 63 MUST be used. Each SFF
+ * involved in forwarding an NSH packet MUST decrement the TTL value by
+ * 1 prior to NSH forwarding lookup. Decrementing by 1 from an incoming
+ * value of 0 shall result in a TTL value of 63. The packet MUST NOT be
+ * forwarded if TTL is, after decrement, 0.
+ *
+ * All other flag fields, marked U, are unassigned and available for
+ * future use, see Section 11.2.1. Unassigned bits MUST be set to zero
+ * upon origination, and MUST be ignored and preserved unmodified by
+ * other NSH supporting elements. Elements which do not understand the
+ * meaning of any of these bits MUST NOT modify their actions based on
+ * those unknown bits.
+ *
+ * Length: The total length, in 4-byte words, of NSH including the Base
+ * Header, the Service Path Header, the Fixed Length Context Header or
+ * Variable Length Context Header(s). The length MUST be 0x6 for MD
+ * Type equal to 0x1, and MUST be 0x2 or greater for MD Type equal to
+ * 0x2. The length of the NSH header MUST be an integer multiple of 4
+ * bytes, thus variable length metadata is always padded out to a
+ * multiple of 4 bytes.
+ *
+ * MD Type: Indicates the format of NSH beyond the mandatory Base Header
+ * and the Service Path Header. MD Type defines the format of the
+ * metadata being carried.
+ *
+ * 0x0 - This is a reserved value. Implementations SHOULD silently
+ * discard packets with MD Type 0x0.
+ *
+ * 0x1 - This indicates that the format of the header includes a fixed
+ * length Context Header (see Figure 4 below).
+ *
+ * 0x2 - This does not mandate any headers beyond the Base Header and
+ * Service Path Header, but may contain optional variable length Context
+ * Header(s). The semantics of the variable length Context Header(s)
+ * are not defined in this document. The format of the optional
+ * variable length Context Headers is provided in Section 2.5.1.
+ *
+ * 0xF - This value is reserved for experimentation and testing, as per
+ * [RFC3692]. Implementations not explicitly configured to be part of
+ * an experiment SHOULD silently discard packets with MD Type 0xF.
+ *
+ * Next Protocol: indicates the protocol type of the encapsulated data.
+ * NSH does not alter the inner payload, and the semantics on the inner
+ * protocol remain unchanged due to NSH service function chaining.
+ * Please see the IANA Considerations section below, Section 11.2.5.
+ *
+ * This document defines the following Next Protocol values:
+ *
+ * 0x1: IPv4
+ * 0x2: IPv6
+ * 0x3: Ethernet
+ * 0x4: NSH
+ * 0x5: MPLS
+ * 0xFE: Experiment 1
+ * 0xFF: Experiment 2
+ *
+ * Packets with Next Protocol values not supported SHOULD be silently
+ * dropped by default, although an implementation MAY provide a
+ * configuration parameter to forward them. Additionally, an
+ * implementation not explicitly configured for a specific experiment
+ * [RFC3692] SHOULD silently drop packets with Next Protocol values 0xFE
+ * and 0xFF.
+ *
+ * Service Path Identifier (SPI): Identifies a service path.
+ * Participating nodes MUST use this identifier for Service Function
+ * Path selection. The initial classifier MUST set the appropriate SPI
+ * for a given classification result.
+ *
+ * Service Index (SI): Provides location within the SFP. The initial
+ * classifier for a given SFP SHOULD set the SI to 255, however the
+ * control plane MAY configure the initial value of SI as appropriate
+ * (i.e., taking into account the length of the service function path).
+ * The Service Index MUST be decremented by a value of 1 by Service
+ * Functions or by SFC Proxy nodes after performing required services
+ * and the new decremented SI value MUST be used in the egress packet's
+ * NSH. The initial Classifier MUST send the packet to the first SFF in
+ * the identified SFP for forwarding along an SFP. If re-classification
+ * occurs, and that re-classification results in a new SPI, the
+ * (re)classifier is, in effect, the initial classifier for the
+ * resultant SPI.
+ *
+ * The SI is used in conjunction the with Service Path Identifier for
+ * Service Function Path Selection and for determining the next SFF/SF
+ * in the path. The SI is also valuable when troubleshooting or
+ * reporting service paths. Additionally, while the TTL field is the
+ * main mechanism for service plane loop detection, the SI can also be
+ * used for detecting service plane loops.
+ *
+ * When the Base Header specifies MD Type = 0x1, a Fixed Length Context
+ * Header (16-bytes) MUST be present immediately following the Service
+ * Path Header. The value of a Fixed Length Context
+ * Header that carries no metadata MUST be set to zero.
+ *
+ * When the base header specifies MD Type = 0x2, zero or more Variable
+ * Length Context Headers MAY be added, immediately following the
+ * Service Path Header (see Figure 5). Therefore, Length = 0x2,
+ * indicates that only the Base Header followed by the Service Path
+ * Header are present. The optional Variable Length Context Headers
+ * MUST be of an integer number of 4-bytes. The base header Length
+ * field MUST be used to determine the offset to locate the original
+ * packet or frame for SFC nodes that require access to that
+ * information.
+ *
+ * The format of the optional variable length Context Headers
+ *
+ * 0 1 2 3
+ * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Metadata Class | Type |U| Length |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Variable Metadata |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *
+ * Metadata Class (MD Class): Defines the scope of the 'Type' field to
+ * provide a hierarchical namespace. The IANA Considerations
+ * Section 11.2.4 defines how the MD Class values can be allocated to
+ * standards bodies, vendors, and others.
+ *
+ * Type: Indicates the explicit type of metadata being carried. The
+ * definition of the Type is the responsibility of the MD Class owner.
+ *
+ * Unassigned bit: One unassigned bit is available for future use. This
+ * bit MUST NOT be set, and MUST be ignored on receipt.
+ *
+ * Length: Indicates the length of the variable metadata, in bytes. In
+ * case the metadata length is not an integer number of 4-byte words,
+ * the sender MUST add pad bytes immediately following the last metadata
+ * byte to extend the metadata to an integer number of 4-byte words.
+ * The receiver MUST round up the length field to the nearest 4-byte
+ * word boundary, to locate and process the next field in the packet.
+ * The receiver MUST access only those bytes in the metadata indicated
+ * by the length field (i.e., actual number of bytes) and MUST ignore
+ * the remaining bytes up to the nearest 4-byte word boundary. The
+ * Length may be 0 or greater.
+ *
+ * A value of 0 denotes a Context Header without a Variable Metadata
+ * field.
+ *
+ * [0] https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/
+ */
+
+/**
+ * struct nsh_md1_ctx - Keeps track of NSH context data
+ * @nshc<1-4>: NSH Contexts.
+ */
+struct nsh_md1_ctx {
+ __be32 context[4];
+};
+
+struct nsh_md2_tlv {
+ __be16 md_class;
+ u8 type;
+ u8 length;
+ u8 md_value[];
+};
+
+struct nshhdr {
+ __be16 ver_flags_ttl_len;
+ u8 mdtype;
+ u8 np;
+ __be32 path_hdr;
+ union {
+ struct nsh_md1_ctx md1;
+ struct nsh_md2_tlv md2;
+ };
+};
+
+/* Masking NSH header fields. */
+#define NSH_VER_MASK 0xc000
+#define NSH_VER_SHIFT 14
+#define NSH_FLAGS_MASK 0x3000
+#define NSH_FLAGS_SHIFT 12
+#define NSH_TTL_MASK 0x0fc0
+#define NSH_TTL_SHIFT 6
+#define NSH_LEN_MASK 0x003f
+#define NSH_LEN_SHIFT 0
+
+#define NSH_MDTYPE_MASK 0x0f
+#define NSH_MDTYPE_SHIFT 0
+
+#define NSH_SPI_MASK 0xffffff00
+#define NSH_SPI_SHIFT 8
+#define NSH_SI_MASK 0x000000ff
+#define NSH_SI_SHIFT 0
+
+/* MD Type Registry. */
+#define NSH_M_TYPE1 0x01
+#define NSH_M_TYPE2 0x02
+#define NSH_M_EXP1 0xFE
+#define NSH_M_EXP2 0xFF
+
+/* NSH Base Header Length */
+#define NSH_BASE_HDR_LEN 8
+
+/* NSH MD Type 1 header Length. */
+#define NSH_M_TYPE1_LEN 24
+
+/* NSH header maximum Length. */
+#define NSH_HDR_MAX_LEN 256
+
+/* NSH context headers maximum Length. */
+#define NSH_CTX_HDRS_MAX_LEN 248
+
+static inline struct nshhdr *nsh_hdr(struct sk_buff *skb)
+{
+ return (struct nshhdr *)skb_network_header(skb);
+}
+
+static inline u16 nsh_hdr_len(const struct nshhdr *nsh)
+{
+ return ((ntohs(nsh->ver_flags_ttl_len) & NSH_LEN_MASK)
+ >> NSH_LEN_SHIFT) << 2;
+}
+
+static inline u8 nsh_get_ver(const struct nshhdr *nsh)
+{
+ return (ntohs(nsh->ver_flags_ttl_len) & NSH_VER_MASK)
+ >> NSH_VER_SHIFT;
+}
+
+static inline u8 nsh_get_flags(const struct nshhdr *nsh)
+{
+ return (ntohs(nsh->ver_flags_ttl_len) & NSH_FLAGS_MASK)
+ >> NSH_FLAGS_SHIFT;
+}
+
+static inline u8 nsh_get_ttl(const struct nshhdr *nsh)
+{
+ return (ntohs(nsh->ver_flags_ttl_len) & NSH_TTL_MASK)
+ >> NSH_TTL_SHIFT;
+}
+
+static inline void __nsh_set_xflag(struct nshhdr *nsh, u16 xflag, u16 xmask)
+{
+ nsh->ver_flags_ttl_len
+ = (nsh->ver_flags_ttl_len & ~htons(xmask)) | htons(xflag);
+}
+
+static inline void nsh_set_flags_and_ttl(struct nshhdr *nsh, u8 flags, u8 ttl)
+{
+ __nsh_set_xflag(nsh, ((flags << NSH_FLAGS_SHIFT) & NSH_FLAGS_MASK) |
+ ((ttl << NSH_TTL_SHIFT) & NSH_TTL_MASK),
+ NSH_FLAGS_MASK | NSH_TTL_MASK);
+}
+
+static inline void nsh_set_flags_ttl_len(struct nshhdr *nsh, u8 flags,
+ u8 ttl, u8 len)
+{
+ len = len >> 2;
+ __nsh_set_xflag(nsh, ((flags << NSH_FLAGS_SHIFT) & NSH_FLAGS_MASK) |
+ ((ttl << NSH_TTL_SHIFT) & NSH_TTL_MASK) |
+ ((len << NSH_LEN_SHIFT) & NSH_LEN_MASK),
+ NSH_FLAGS_MASK | NSH_TTL_MASK | NSH_LEN_MASK);
+}
+
+#endif /* __NET_NSH_H */
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 2/4] vxlan: factor out VXLAN-GPE next protocol
From: Jiri Benc @ 2017-08-28 19:43 UTC (permalink / raw)
To: netdev; +Cc: Yi Yang, Eric Garver, Jan Scheurich, Ben Pfaff
In-Reply-To: <cover.1503948295.git.jbenc@redhat.com>
The values are shared between VXLAN-GPE and NSH. Originally probably by
coincidence but I notified both working groups about this last year and they
seem to keep the values in sync since then.
Hopefully they'll get a single IANA registry for the values, too. (I asked
them for that.)
Factor out the code to be shared by the NSH implementation.
NSH and MPLS values are added in this patch, too. For MPLS, the drafts
incorrectly assign only a single value, while we have two MPLS ethertypes.
I raised the problem with both groups. For now, I assume the value is for
unicast.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
drivers/net/vxlan.c | 32 +++++++-------------------------
include/net/tun_proto.h | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
include/net/vxlan.h | 6 ------
3 files changed, 56 insertions(+), 31 deletions(-)
create mode 100644 include/net/tun_proto.h
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index ae3a1da703c2..d7c49cf1d5e9 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -26,6 +26,7 @@
#include <net/inet_ecn.h>
#include <net/net_namespace.h>
#include <net/netns/generic.h>
+#include <net/tun_proto.h>
#include <net/vxlan.h>
#if IS_ENABLED(CONFIG_IPV6)
@@ -1261,19 +1262,9 @@ static bool vxlan_parse_gpe_hdr(struct vxlanhdr *unparsed,
if (gpe->oam_flag)
return false;
- switch (gpe->next_protocol) {
- case VXLAN_GPE_NP_IPV4:
- *protocol = htons(ETH_P_IP);
- break;
- case VXLAN_GPE_NP_IPV6:
- *protocol = htons(ETH_P_IPV6);
- break;
- case VXLAN_GPE_NP_ETHERNET:
- *protocol = htons(ETH_P_TEB);
- break;
- default:
+ *protocol = tun_p_to_eth_p(gpe->next_protocol);
+ if (!*protocol)
return false;
- }
unparsed->vx_flags &= ~VXLAN_GPE_USED_BITS;
return true;
@@ -1799,19 +1790,10 @@ static int vxlan_build_gpe_hdr(struct vxlanhdr *vxh, u32 vxflags,
struct vxlanhdr_gpe *gpe = (struct vxlanhdr_gpe *)vxh;
gpe->np_applied = 1;
-
- switch (protocol) {
- case htons(ETH_P_IP):
- gpe->next_protocol = VXLAN_GPE_NP_IPV4;
- return 0;
- case htons(ETH_P_IPV6):
- gpe->next_protocol = VXLAN_GPE_NP_IPV6;
- return 0;
- case htons(ETH_P_TEB):
- gpe->next_protocol = VXLAN_GPE_NP_ETHERNET;
- return 0;
- }
- return -EPFNOSUPPORT;
+ gpe->next_protocol = tun_p_from_eth_p(protocol);
+ if (!gpe->next_protocol)
+ return -EPFNOSUPPORT;
+ return 0;
}
static int vxlan_build_skb(struct sk_buff *skb, struct dst_entry *dst,
diff --git a/include/net/tun_proto.h b/include/net/tun_proto.h
new file mode 100644
index 000000000000..2ea3deba4c99
--- /dev/null
+++ b/include/net/tun_proto.h
@@ -0,0 +1,49 @@
+#ifndef __NET_TUN_PROTO_H
+#define __NET_TUN_PROTO_H
+
+#include <linux/kernel.h>
+
+/* One byte protocol values as defined by VXLAN-GPE and NSH. These will
+ * hopefully get a shared IANA registry.
+ */
+#define TUN_P_IPV4 0x01
+#define TUN_P_IPV6 0x02
+#define TUN_P_ETHERNET 0x03
+#define TUN_P_NSH 0x04
+#define TUN_P_MPLS_UC 0x05
+
+static inline __be16 tun_p_to_eth_p(u8 proto)
+{
+ switch (proto) {
+ case TUN_P_IPV4:
+ return htons(ETH_P_IP);
+ case TUN_P_IPV6:
+ return htons(ETH_P_IPV6);
+ case TUN_P_ETHERNET:
+ return htons(ETH_P_TEB);
+ case TUN_P_NSH:
+ return htons(ETH_P_NSH);
+ case TUN_P_MPLS_UC:
+ return htons(ETH_P_MPLS_UC);
+ }
+ return 0;
+}
+
+static inline u8 tun_p_from_eth_p(__be16 proto)
+{
+ switch (proto) {
+ case htons(ETH_P_IP):
+ return TUN_P_IPV4;
+ case htons(ETH_P_IPV6):
+ return TUN_P_IPV6;
+ case htons(ETH_P_TEB):
+ return TUN_P_ETHERNET;
+ case htons(ETH_P_NSH):
+ return TUN_P_NSH;
+ case htons(ETH_P_MPLS_UC):
+ return TUN_P_MPLS_UC;
+ }
+ return 0;
+}
+
+#endif
diff --git a/include/net/vxlan.h b/include/net/vxlan.h
index 3f430e38ab82..4e3876dde295 100644
--- a/include/net/vxlan.h
+++ b/include/net/vxlan.h
@@ -168,12 +168,6 @@ struct vxlanhdr_gpe {
#define VXLAN_GPE_USED_BITS (VXLAN_HF_VER | VXLAN_HF_NP | VXLAN_HF_OAM | \
cpu_to_be32(0xff))
-/* VXLAN-GPE header Next Protocol. */
-#define VXLAN_GPE_NP_IPV4 0x01
-#define VXLAN_GPE_NP_IPV6 0x02
-#define VXLAN_GPE_NP_ETHERNET 0x03
-#define VXLAN_GPE_NP_NSH 0x04
-
struct vxlan_metadata {
u32 gbp;
};
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 1/4] ether: add NSH ethertype
From: Jiri Benc @ 2017-08-28 19:43 UTC (permalink / raw)
To: netdev; +Cc: Yi Yang, Eric Garver, Jan Scheurich, Ben Pfaff
In-Reply-To: <cover.1503948295.git.jbenc@redhat.com>
The NSH draft says:
An IEEE EtherType, 0x894F, has been allocated for NSH.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
include/uapi/linux/if_ether.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/if_ether.h b/include/uapi/linux/if_ether.h
index efeb1190c2ca..d7b47e97904f 100644
--- a/include/uapi/linux/if_ether.h
+++ b/include/uapi/linux/if_ether.h
@@ -99,6 +99,7 @@
#define ETH_P_FIP 0x8914 /* FCoE Initialization Protocol */
#define ETH_P_80221 0x8917 /* IEEE 802.21 Media Independent Handover Protocol */
#define ETH_P_HSR 0x892F /* IEC 62439-3 HSRv1 */
+#define ETH_P_NSH 0x894F /* Network Service Header */
#define ETH_P_LOOPBACK 0x9000 /* Ethernet loopback packet, per IEEE 802.3 */
#define ETH_P_QINQ1 0x9100 /* deprecated QinQ VLAN [ NOT AN OFFICIALLY REGISTERED ID ] */
#define ETH_P_QINQ2 0x9200 /* deprecated QinQ VLAN [ NOT AN OFFICIALLY REGISTERED ID ] */
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 0/4] nsh: headers, GSO
From: Jiri Benc @ 2017-08-28 19:43 UTC (permalink / raw)
To: netdev; +Cc: Yi Yang, Eric Garver, Jan Scheurich, Ben Pfaff
This adds header structs and helpers for NSH together with GSO support.
Note there is no code in this patchset that actually manipulates the NSH
headers. That was sent to netdev by Yi Yang ("[PATCH net-next v6 0/3]
openvswitch: add NSH support"). The aim of this series is to lay the
groundwork and ease the implementation for him.
In addition to openvswitch, the NSH support should be added to tc (flower to
match, act_nsh to push/pop NSH headers). That will come later. There's
currently no plan to support NSH by other means than those two.
The patch 3 in this patchset was written by Yi Yang, I took it from the
aforementioned series and slightly modified it - see the note in the patch.
Jiri Benc (3):
ether: add NSH ethertype
vxlan: factor out VXLAN-GPE next protocol
nsh: add GSO support
Yi Yang (1):
net: add NSH header structures and helpers
drivers/net/vxlan.c | 32 +----
include/net/nsh.h | 307 ++++++++++++++++++++++++++++++++++++++++++
include/net/tun_proto.h | 49 +++++++
include/net/vxlan.h | 6 -
include/uapi/linux/if_ether.h | 1 +
net/Kconfig | 1 +
net/Makefile | 1 +
net/nsh/Kconfig | 9 ++
net/nsh/Makefile | 1 +
net/nsh/nsh.c | 91 +++++++++++++
10 files changed, 467 insertions(+), 31 deletions(-)
create mode 100644 include/net/nsh.h
create mode 100644 include/net/tun_proto.h
create mode 100644 net/nsh/Kconfig
create mode 100644 net/nsh/Makefile
create mode 100644 net/nsh/nsh.c
--
1.8.3.1
^ permalink raw reply
* Re: XDP redirect measurements, gotchas and tracepoints
From: Andy Gospodarek @ 2017-08-28 19:39 UTC (permalink / raw)
To: John Fastabend
Cc: Michael Chan, Jesper Dangaard Brouer, Alexander Duyck,
Duyck, Alexander H, pstaszewski@itcare.pl, netdev@vger.kernel.org,
xdp-newbies@vger.kernel.org, borkmann@iogearbox.net
In-Reply-To: <59A4415C.80702@gmail.com>
On Mon, Aug 28, 2017 at 09:14:20AM -0700, John Fastabend wrote:
> On 08/28/2017 09:02 AM, Andy Gospodarek wrote:
> > On Fri, Aug 25, 2017 at 08:28:55AM -0700, Michael Chan wrote:
> >> On Fri, Aug 25, 2017 at 8:10 AM, John Fastabend
> >> <john.fastabend@gmail.com> wrote:
> >>> On 08/25/2017 05:45 AM, Jesper Dangaard Brouer wrote:
> >>>> On Thu, 24 Aug 2017 20:36:28 -0700
> >>>> Michael Chan <michael.chan@broadcom.com> wrote:
> >>>>
> >>>>> On Wed, Aug 23, 2017 at 1:29 AM, Jesper Dangaard Brouer
> >>>>> <brouer@redhat.com> wrote:
> >>>>>> On Tue, 22 Aug 2017 23:59:05 -0700
> >>>>>> Michael Chan <michael.chan@broadcom.com> wrote:
> >>>>>>
> >>>>>>> On Tue, Aug 22, 2017 at 6:06 PM, Alexander Duyck
> >>>>>>> <alexander.duyck@gmail.com> wrote:
> >>>>>>>> On Tue, Aug 22, 2017 at 1:04 PM, Michael Chan <michael.chan@broadcom.com> wrote:
> >>>>>>>>>
> >>>>>>>>> Right, but it's conceivable to add an API to "return" the buffer to
> >>>>>>>>> the input device, right?
> >>>>>>
> >>>>>> Yes, I would really like to see an API like this.
> >>>>>>
> >>>>>>>>
> >>>>>>>> You could, it is just added complexity. "just free the buffer" in
> >>>>>>>> ixgbe usually just amounts to one atomic operation to decrement the
> >>>>>>>> total page count since page recycling is already implemented in the
> >>>>>>>> driver. You still would have to unmap the buffer regardless of if you
> >>>>>>>> were recycling it or not so all you would save is 1.000015259 atomic
> >>>>>>>> operations per packet. The fraction is because once every 64K uses we
> >>>>>>>> have to bulk update the count on the page.
> >>>>>>>>
> >>>>>>>
> >>>>>>> If the buffer is returned to the input device, the input device can
> >>>>>>> keep the DMA mapping. All it needs to do is to dma_sync it back to
> >>>>>>> the input device when the buffer is returned.
> >>>>>>
> >>>>>> Yes, exactly, return to the input device. I really think we should
> >>>>>> work on a solution where we can keep the DMA mapping around. We have
> >>>>>> an opportunity here to make ndo_xdp_xmit TX queues use a specialized
> >>>>>> page return call, to achieve this. (I imagine other arch's have a high
> >>>>>> DMA overhead than Intel)
> >>>>>>
> >>>>>> I'm not sure how the API should look. The ixgbe recycle mechanism and
> >>>>>> splitting the page (into two packets) actually complicates things, and
> >>>>>> tie us into a page-refcnt based model. We could get around this by
> >>>>>> each driver implementing a page-return-callback, that allow us to
> >>>>>> return the page to the input device? Then, drivers implementing the
> >>>>>> 1-packet-per-page can simply check/read the page-refcnt, and if it is
> >>>>>> "1" DMA-sync and reuse it in the RX queue.
> >>>>>>
> >>>>>
> >>>>> Yeah, based on Alex' description, it's not clear to me whether ixgbe
> >>>>> redirecting to a non-intel NIC or vice versa will actually work. It
> >>>>> sounds like the output device has to make some assumptions about how
> >>>>> the page was allocated by the input device.
> >>>>
> >>>> Yes, exactly. We are tied into a page refcnt based scheme.
> >>>>
> >>>> Besides the ixgbe page recycle scheme (which keeps the DMA RX-mapping)
> >>>> is also tied to the RX queue size, plus how fast the pages are returned.
> >>>> This makes it very hard to tune. As I demonstrated, default ixgbe
> >>>> settings does not work well with XDP_REDIRECT. I needed to increase
> >>>> TX-ring size, but it broke page recycling (dropping perf from 13Mpps to
> >>>> 10Mpps) so I also needed it increase RX-ring size. But perf is best if
> >>>> RX-ring size is smaller, thus two contradicting tuning needed.
> >>>>
> >>>
> >>> The changes to decouple the ixgbe page recycle scheme (1pg per descriptor
> >>> split into two halves being the default) from the number of descriptors
> >>> doesn't look too bad IMO. It seems like it could be done by having some
> >>> extra pages allocated upfront and pulling those in when we need another
> >>> page.
> >>>
> >>> This would be a nice iterative step we could take on the existing API.
> >>>
> >>>>
> >>>>> With buffer return API,
> >>>>> each driver can cleanly recycle or free its own buffers properly.
> >>>>
> >>>> Yes, exactly. And RX-driver can implement a special memory model for
> >>>> this queue. E.g. RX-driver can know this is a dedicated XDP RX-queue
> >>>> which is never used for SKBs, thus opening for new RX memory models.
> >>>>
> >>>> Another advantage of a return API. There is also an opportunity for
> >>>> avoiding the DMA map on TX. As we need to know the from-device. Thus,
> >>>> we can add a DMA API, where we can query if the two devices uses the
> >>>> same DMA engine, and can reuse the same DMA address the RX-side already
> >>>> knows.
> >>>>
> >>>>
> >>>>> Let me discuss this further with Andy to see if we can come up with a
> >>>>> good scheme.
> >>>>
> >>>> Sound good, looking forward to hear what you come-up with :-)
> >>>>
> >>>
> >>> I guess by this thread we will see a broadcom nic with redirect support
> >>> soon ;)
> >>
> >> Yes, Andy actually has finished the coding for XDP_REDIRECT, but the
> >> buffer recycling scheme has some problems. We can make it work for
> >> Broadcom to Broadcom only, but we want a better solution.
> >
> > (Sorry for the radio silence I was AFK last week...)
> >
> > I finished it a little while ago, but Michael and I both have concerns
> > that in a heterogenous hardware setup one can quickly run into issues
> > and haven't had time to work-up a few solutions before bringing this up
> > formally. It also isn't a major problem until the second
> > optimized/native XDP driver appears on the scene.
> >
> > I can run a test where XDP redirects from an ixgbe <-> bnxt_en based
> > device I get OOM kills after only a few seconds, due to the lack of
> > feedback between the different drivers that the pointer to xdp->data can
> > be freed/reused/etc and the different buffer allocation schemes used.
> >
>
> hmm so how do you get OOM here, I expect the number of in-flight xdp
> bufs should be limited by the number of xdps that can be posted to the
> outgoing interface. If we are hitting OOM that _should_ mean the size of
> the tx queue is too large. Ixgbe should be free'ing the buffer if an error
> is returned from xdp xmit routines (will check this today). And bnxt should
> return an error if we hit some high water mark on xmit.
I reconfigured the hardware after I was done with the bnxt_en devel, but I
should be able to set it up and provide some more detail. Let me repro it and
debug a bit more.
>
> > Initially I did not think this was an issue and that xdp_do_flush_map()
> > would handle this, but I think there is a still a need to be able to
> > signal back to the receving device that the buffer allocated has been
> > xmitted by the transmitter and can be freed. Since there is really no
> > guarantee that completion of an XDP_REDIRECT action means that it is
> > safe to free area pointed to by xdp->data area that contains the packet
> > to be xmitted. Since the packet done interrupt handler in a driver
> > cannot signal back the the receiving driver that the buffer is now safe
> > to reuse/free there is a chance for trouble.
>
> There should be some high water mark on how many outstanding packets
> can be in-flight. At the moment I assumed this was something related to
> queue lengths a more explicit high water mark could added to the xmit path
> and tracked in xdp infrastructure.
>
> >
> > I was hoping to spend some time this week cooking up a patch that just
> > did not allow use of XDP_REDIRECT when the ifindex of the outgoing
> > device did not match that of the device to which the XDP prog was
> > attached, but that probably is not worth the trouble when we would just
> > fix it for real. (It would also require some really terrible hacks to
> > enforce this in the kernel when all that is being done is setting up a
> > map that contains the redirect table, so it is probably not useful.)
> >
>
> I would prefer to solve the problem vs limiting the implementation
>
Agreed.
> > The basic prototype would be something like this:
> >
> > (rx packet interrupt on eth0, leads to napi_poll)
> > napi_poll (eth0)
> > call xdp_prog (eth0)
> > xdp_do_redirect (eth0)
> > ndo_xdp_xmit (eth1)
> > mark buffer with information netdev/ring/etc
> > place buffer on tx ring for eth1
> >
> > (tx done interrupt on eth1, leads to napi_poll)
> > napi_poll (eth1)
> > process tx interrupt (eth1)
> > look up information about netdev/ring/etc
> > ndo_xdp_data_free (eth0, ring, etc)
> >
> > Thoughts?
> >
>
^ permalink raw reply
* Re: [PATCH iproute2 1/4] tc: m_ife: allow ife type to zero
From: Stephen Hemminger @ 2017-08-28 19:34 UTC (permalink / raw)
To: Alexander Aring; +Cc: jhs, yotamg, xiyou.wangcong, jiri, netdev
In-Reply-To: <20170828190738.26829-2-aring@mojatatu.com>
On Mon, 28 Aug 2017 15:07:35 -0400
Alexander Aring <aring@mojatatu.com> wrote:
> This patch allows to set an ethertype for IFE which is zero. There is no
> kernel side validation which forbids a type to zero.
>
> Signed-off-by: Alexander Aring <aring@mojatatu.com>
> ---
> tc/m_ife.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/tc/m_ife.c b/tc/m_ife.c
> index e3521e62..e05e2276 100644
> --- a/tc/m_ife.c
> +++ b/tc/m_ife.c
> @@ -63,6 +63,7 @@ static int parse_ife(struct action_util *a, int *argc_p, char ***argv_p,
> char dbuf[ETH_ALEN];
> char sbuf[ETH_ALEN];
> __u16 ife_type = 0;
> + int user_type = 0;
Please use bool if it is a flag value
^ 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