* Re: [patch net-next 0/2] Fixes for raw diag sockets handling
From: David Ahern @ 2016-11-02 15:10 UTC (permalink / raw)
To: Cyrill Gorcunov, netdev
Cc: Eric Dumazet, David S. Miller, Andrey Vagin, Stephen Hemminger
In-Reply-To: <20161102123630.784612652@openvz.org>
On 11/2/16 6:36 AM, Cyrill Gorcunov wrote:
> Also I have a question about sockets lookup not for raw diag only
> (though I didn't modify lookup procedure) but in general: the structure
> inet_diag_req_v2 has inet_diag_sockid::idiag_if member which supposed to
> carry interface index from userspace request.
>
> Then for example in INET_MATCH (include/net/inet_hashtables.h),
> the __dif parameter (which is @idiag_if) compared with @sk_bound_dev_if
> *iif* the sk_bound_dev_if has been ever set. Thus if say someone
> looks up for paticular device with specified index if the
> rest of parameters match and SO_BINDTODEVICE never been called
> for this device we return the socket even if idiag_if is not zero.
> Is it supposed to be so? Or I miss something obvious?
>
> I mean this snippet
>
>
> (!(__sk)->sk_bound_dev_if || \
> ((__sk)->sk_bound_dev_if == (__dif))) && \
>
> when someone calls for destory sockets on particular interface and
> @__dif != 0 the match may return socket where sk_bound_dev_if = 0
> instead of completely matching one. Isn't it?
yes. I recently added an exact_dif to the lookup for listener sockets (see compute_score). Something like that could be added to INET_MATCH.
^ permalink raw reply
* [PATCH iproute2] tc: flower: Fix usage message
From: Paul Blakey @ 2016-11-02 15:09 UTC (permalink / raw)
To: netdev; +Cc: Or Gerlitz, Paul Blakey
Remove left over usage from removal of eth_type argument.
Fixes: 488b41d020fb ('tc: flower no need to specify the ethertype')
Signed-off-by: Paul Blakey <paulb@mellanox.com>
---
man/man8/tc-flower.8 | 9 ---------
tc/f_flower.c | 3 +--
2 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/man/man8/tc-flower.8 b/man/man8/tc-flower.8
index 74f7664..16ef261 100644
--- a/man/man8/tc-flower.8
+++ b/man/man8/tc-flower.8
@@ -23,8 +23,6 @@ flower \- flow based traffic control filter
.R " | { "
.BR dst_mac " | " src_mac " } "
.IR mac_address " | "
-.BR eth_type " { " ipv4 " | " ipv6 " | " 802.1Q " | "
-.IR ETH_TYPE " } | "
.B vlan_id
.IR VID " | "
.B vlan_prio
@@ -75,13 +73,6 @@ Do not process filter by hardware.
.BI src_mac " mac_address"
Match on source or destination MAC address.
.TP
-.BI eth_type " ETH_TYPE"
-Match on the next protocol.
-.I ETH_TYPE
-may be either
-.BR ipv4 , ipv6 , 802.1Q ,
-or an unsigned 16bit value in hexadecimal format.
-.TP
.BI vlan_id " VID"
Match on vlan tag id.
.I VID
diff --git a/tc/f_flower.c b/tc/f_flower.c
index 2d31d1a..f39b1f7 100644
--- a/tc/f_flower.c
+++ b/tc/f_flower.c
@@ -36,7 +36,6 @@ static void explain(void)
fprintf(stderr, " vlan_ethtype [ ipv4 | ipv6 | ETH-TYPE ] |\n");
fprintf(stderr, " dst_mac MAC-ADDR |\n");
fprintf(stderr, " src_mac MAC-ADDR |\n");
- fprintf(stderr, " [ipv4 | ipv6 ] |\n");
fprintf(stderr, " ip_proto [tcp | udp | IP-PROTO ] |\n");
fprintf(stderr, " dst_ip [ IPV4-ADDR | IPV6-ADDR ] |\n");
fprintf(stderr, " src_ip [ IPV4-ADDR | IPV6-ADDR ] |\n");
@@ -45,7 +44,7 @@ static void explain(void)
fprintf(stderr, " FILTERID := X:Y:Z\n");
fprintf(stderr, " ACTION-SPEC := ... look at individual actions\n");
fprintf(stderr, "\n");
- fprintf(stderr, "NOTE: CLASSID, ETH-TYPE, IP-PROTO are parsed as hexadecimal input.\n");
+ fprintf(stderr, "NOTE: CLASSID, IP-PROTO are parsed as hexadecimal input.\n");
fprintf(stderr, "NOTE: There can be only used one mask per one prio. If user needs\n");
fprintf(stderr, " to specify different mask, he has to use different prio.\n");
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next 3/3] tools lib bpf: Sync bpf_map_def with tc
From: Daniel Borkmann @ 2016-11-02 15:08 UTC (permalink / raw)
To: Joe Stringer; +Cc: netdev, wangnan0, ast
In-Reply-To: <5819F461.7050309@iogearbox.net>
On 11/02/2016 03:12 PM, Daniel Borkmann wrote:
> On 11/02/2016 05:09 AM, Joe Stringer wrote:
>> On 1 November 2016 at 20:09, Daniel Borkmann <daniel@iogearbox.net> wrote:
>>> On 10/31/2016 07:39 PM, Joe Stringer wrote:
>>>>
>>>> TC uses a slightly different map layout in its ELFs. Update libbpf to
>>>> use the same definition so that ELFs may be built using libbpf and
>>>> loaded using tc.
>>>>
>>>> Signed-off-by: Joe Stringer <joe@ovn.org>
>>>> ---
>>>> tools/lib/bpf/libbpf.h | 11 +++++++----
>>>> 1 file changed, 7 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
>>>> index dd7a513efb10..ea70c2744f8c 100644
>>>> --- a/tools/lib/bpf/libbpf.h
>>>> +++ b/tools/lib/bpf/libbpf.h
>>>> @@ -181,10 +181,13 @@ bool bpf_program__is_kprobe(struct bpf_program
>>>> *prog);
>>>> * and will be treated as an error due to -Werror.
>>>> */
>>>> struct bpf_map_def {
>>>> - unsigned int type;
>>>> - unsigned int key_size;
>>>> - unsigned int value_size;
>>>> - unsigned int max_entries;
>>>> + uint32_t type;
>>>> + uint32_t key_size;
>>>> + uint32_t value_size;
>>>> + uint32_t max_entries;
>>>> + uint32_t flags;
>>>> + uint32_t id;
>>>> + uint32_t pinning;
>>>> };
>>>>
>>>> /*
>>>
>>> I think the problem is that this would break existing obj files that have
>>> been compiled with the current struct bpf_map_def (besides libbpf not having
>>> a use for the last two members right now).
>>
>> Right, this is a problem. I wasn't sure whether libbpf was yet at a
>> stage where it tries to retain compatibility with binaries compiled
>> against older kernels.
>>
>>> For tc, we have a refactoring of the tc_bpf.c bits that generalizes them so
>>> we can move these bits into iproute2 lib part and add new BPF types really
>>> easily. What I did along with that is to implement a map compat mode, where
>>> it detects the size of struct bpf_elf_map (or however you want to name it)
>>> from the obj file and fixes up the missing members with some reasonable
>>> default,
>>> so these programs can still be loaded. Thus, the sample code using the
>>> current
>>> struct bpf_map_def will then work with tc as well. (I'll post the iproute2
>>> patch early next week.)
>>
>> Are you encoding the number of maps into the start of the maps section
>> in the ELF then using that to divide out and determine the size?
>
> No. It's walking the symbol table and simply counts the number of symbols
> that are present in the maps section with correct st_info attribution. It
> works because that section name is fixed ABI for all cases and really per
> definition only map structs are present there. The minimum attributes which
> are allowed to be loaded are type, key_size, value_size and max_entries.
>
>> I look forward to your patches. Maybe if TC is more tolerant of other
>> map definition sizes then this patch is less relevant.
Just a thought (not really related to your set though): Perhaps it makes sense
for the bpflib, to also add an option where the user passes a callback to parse
the map section itself if something else than struct bpf_map_def is expected in
the obj, and then have a way to access the meta data along with the fd via lib
api later on. Perhaps that would also include another callback passed to the
lib that would take care to invoke bpf(2) for map creation, which could be useful
if some custom interaction with bpffs is desired.
^ permalink raw reply
* [PATCH net-next 3/3] ipv6: on reassembly, record frag_max_size
From: Willem de Bruijn @ 2016-11-02 15:02 UTC (permalink / raw)
To: netdev; +Cc: jdorfman, eric.dumazet, davem, Willem de Bruijn
In-Reply-To: <1478098938-124108-1-git-send-email-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemb@google.com>
IP6CB and IPCB have a frag_max_size field. In IPv6 this field is
filled in when packets are reassembled by the connection tracking
code. Also fill in when reassembling in the input path, to expose
it through cmsg IPV6_RECVFRAGSIZE in all cases.
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
net/ipv6/reassembly.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/reassembly.c b/net/ipv6/reassembly.c
index 3815e85..e1da5b8 100644
--- a/net/ipv6/reassembly.c
+++ b/net/ipv6/reassembly.c
@@ -211,7 +211,7 @@ static int ip6_frag_queue(struct frag_queue *fq, struct sk_buff *skb,
{
struct sk_buff *prev, *next;
struct net_device *dev;
- int offset, end;
+ int offset, end, fragsize;
struct net *net = dev_net(skb_dst(skb)->dev);
u8 ecn;
@@ -336,6 +336,10 @@ static int ip6_frag_queue(struct frag_queue *fq, struct sk_buff *skb,
fq->ecn |= ecn;
add_frag_mem_limit(fq->q.net, skb->truesize);
+ fragsize = -skb_network_offset(skb) + skb->len;
+ if (fragsize > fq->q.max_size)
+ fq->q.max_size = fragsize;
+
/* The first fragment.
* nhoffset is obtained from the first fragment, of course.
*/
@@ -495,6 +499,7 @@ static int ip6_frag_reasm(struct frag_queue *fq, struct sk_buff *prev,
ipv6_change_dsfield(ipv6_hdr(head), 0xff, ecn);
IP6CB(head)->nhoff = nhoff;
IP6CB(head)->flags |= IP6SKB_FRAGMENTED;
+ IP6CB(head)->frag_max_size = fq->q.max_size;
/* Yes, and fold redundant checksum back. 8) */
skb_postpush_rcsum(head, skb_network_header(head),
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH net-next 1/3] ipv4: add IP_RECVFRAGSIZE cmsg
From: Willem de Bruijn @ 2016-11-02 15:02 UTC (permalink / raw)
To: netdev; +Cc: jdorfman, eric.dumazet, davem, Willem de Bruijn
In-Reply-To: <1478098938-124108-1-git-send-email-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemb@google.com>
The IP stack records the largest fragment of a reassembled packet
in IPCB(skb)->frag_max_size. When reading a datagram or raw packet
that arrived fragmented, expose the value to allow applications to
estimate receive path MTU.
Tested:
Sent data over a veth pair of which the source has a small mtu.
Sent data using netcat, received using a dedicated process.
Verified that the cmsg IP_RECVFRAGSIZE is returned only when
data arrives fragmented, and in that cases matches the veth mtu.
ip link add veth0 type veth peer name veth1
ip netns add from
ip netns add to
ip link set dev veth1 netns to
ip netns exec to ip addr add dev veth1 192.168.10.1/24
ip netns exec to ip link set dev veth1 up
ip link set dev veth0 netns from
ip netns exec from ip addr add dev veth0 192.168.10.2/24
ip netns exec from ip link set dev veth0 up
ip netns exec from ip link set dev veth0 mtu 1300
ip netns exec from ethtool -K veth0 ufo off
dd if=/dev/zero bs=1 count=1400 2>/dev/null > payload
ip netns exec to ./recv_cmsg_recvfragsize -4 -u -p 6000 &
ip netns exec from nc -q 1 -u 192.168.10.1 6000 < payload
using github.com/wdebruij/kerneltools/blob/master/tests/recvfragsize.c
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
include/net/inet_sock.h | 1 +
include/uapi/linux/in.h | 1 +
net/ipv4/ip_sockglue.c | 26 ++++++++++++++++++++++++++
3 files changed, 28 insertions(+)
diff --git a/include/net/inet_sock.h b/include/net/inet_sock.h
index 236a810..c9cff97 100644
--- a/include/net/inet_sock.h
+++ b/include/net/inet_sock.h
@@ -228,6 +228,7 @@ struct inet_sock {
#define IP_CMSG_PASSSEC BIT(5)
#define IP_CMSG_ORIGDSTADDR BIT(6)
#define IP_CMSG_CHECKSUM BIT(7)
+#define IP_CMSG_RECVFRAGSIZE BIT(8)
/**
* sk_to_full_sk - Access to a full socket
diff --git a/include/uapi/linux/in.h b/include/uapi/linux/in.h
index eaf9491..4e557f4 100644
--- a/include/uapi/linux/in.h
+++ b/include/uapi/linux/in.h
@@ -117,6 +117,7 @@ struct in_addr {
#define IP_NODEFRAG 22
#define IP_CHECKSUM 23
#define IP_BIND_ADDRESS_NO_PORT 24
+#define IP_RECVFRAGSIZE 25
/* IP_MTU_DISCOVER values */
#define IP_PMTUDISC_DONT 0 /* Never send DF frames */
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index b8a2d63..ecbaae2 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -97,6 +97,17 @@ static void ip_cmsg_recv_retopts(struct msghdr *msg, struct sk_buff *skb)
put_cmsg(msg, SOL_IP, IP_RETOPTS, opt->optlen, opt->__data);
}
+static void ip_cmsg_recv_fragsize(struct msghdr *msg, struct sk_buff *skb)
+{
+ int val;
+
+ if (IPCB(skb)->frag_max_size == 0)
+ return;
+
+ val = IPCB(skb)->frag_max_size;
+ put_cmsg(msg, SOL_IP, IP_RECVFRAGSIZE, sizeof(val), &val);
+}
+
static void ip_cmsg_recv_checksum(struct msghdr *msg, struct sk_buff *skb,
int tlen, int offset)
{
@@ -218,6 +229,9 @@ void ip_cmsg_recv_offset(struct msghdr *msg, struct sk_buff *skb,
if (flags & IP_CMSG_CHECKSUM)
ip_cmsg_recv_checksum(msg, skb, tlen, offset);
+
+ if (flags & IP_CMSG_RECVFRAGSIZE)
+ ip_cmsg_recv_fragsize(msg, skb);
}
EXPORT_SYMBOL(ip_cmsg_recv_offset);
@@ -614,6 +628,7 @@ static int do_ip_setsockopt(struct sock *sk, int level,
case IP_MULTICAST_LOOP:
case IP_RECVORIGDSTADDR:
case IP_CHECKSUM:
+ case IP_RECVFRAGSIZE:
if (optlen >= sizeof(int)) {
if (get_user(val, (int __user *) optval))
return -EFAULT;
@@ -726,6 +741,14 @@ static int do_ip_setsockopt(struct sock *sk, int level,
}
}
break;
+ case IP_RECVFRAGSIZE:
+ if (sk->sk_type != SOCK_RAW && sk->sk_type != SOCK_DGRAM)
+ goto e_inval;
+ if (val)
+ inet->cmsg_flags |= IP_CMSG_RECVFRAGSIZE;
+ else
+ inet->cmsg_flags &= ~IP_CMSG_RECVFRAGSIZE;
+ break;
case IP_TOS: /* This sets both TOS and Precedence */
if (sk->sk_type == SOCK_STREAM) {
val &= ~INET_ECN_MASK;
@@ -1357,6 +1380,9 @@ static int do_ip_getsockopt(struct sock *sk, int level, int optname,
case IP_CHECKSUM:
val = (inet->cmsg_flags & IP_CMSG_CHECKSUM) != 0;
break;
+ case IP_RECVFRAGSIZE:
+ val = (inet->cmsg_flags & IP_CMSG_RECVFRAGSIZE) != 0;
+ break;
case IP_TOS:
val = inet->tos;
break;
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH net-next 2/3] ipv6: add IPV6_RECVFRAGSIZE cmsg
From: Willem de Bruijn @ 2016-11-02 15:02 UTC (permalink / raw)
To: netdev; +Cc: jdorfman, eric.dumazet, davem, Willem de Bruijn
In-Reply-To: <1478098938-124108-1-git-send-email-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemb@google.com>
When reading a datagram or raw packet that arrived fragmented, expose
the maximum fragment size if recorded to allow applications to
estimate receive path MTU.
At this point, the field is only recorded when ipv6 connection
tracking is enabled. A follow-up patch will record this field also
in the ipv6 input path.
Tested using the test for IP_RECVFRAGSIZE plus
ip netns exec to ip addr add dev veth1 fc07::1/64
ip netns exec from ip addr add dev veth0 fc07::2/64
ip netns exec to ./recv_cmsg_recvfragsize -6 -u -p 6000 &
ip netns exec from nc -q 1 -u fc07::1 6000 < payload
Both with and without enabling connection tracking
ip6tables -A INPUT -m state --state NEW -p udp -j LOG
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
include/linux/ipv6.h | 5 +++--
include/uapi/linux/in6.h | 1 +
net/ipv6/datagram.c | 5 +++++
net/ipv6/ipv6_sockglue.c | 8 ++++++++
4 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index ca1ad9e..1afb6e8 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -229,8 +229,9 @@ struct ipv6_pinfo {
rxflow:1,
rxtclass:1,
rxpmtu:1,
- rxorigdstaddr:1;
- /* 2 bits hole */
+ rxorigdstaddr:1,
+ recvfragsize:1;
+ /* 1 bits hole */
} bits;
__u16 all;
} rxopt;
diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
index b39ea4f..46444f8 100644
--- a/include/uapi/linux/in6.h
+++ b/include/uapi/linux/in6.h
@@ -283,6 +283,7 @@ struct in6_flowlabel_req {
#define IPV6_RECVORIGDSTADDR IPV6_ORIGDSTADDR
#define IPV6_TRANSPARENT 75
#define IPV6_UNICAST_IF 76
+#define IPV6_RECVFRAGSIZE 77
/*
* Multicast Routing:
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index 37874e2..620c79a 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -715,6 +715,11 @@ void ip6_datagram_recv_specific_ctl(struct sock *sk, struct msghdr *msg,
put_cmsg(msg, SOL_IPV6, IPV6_ORIGDSTADDR, sizeof(sin6), &sin6);
}
}
+ if (np->rxopt.bits.recvfragsize && opt->frag_max_size) {
+ int val = opt->frag_max_size;
+
+ put_cmsg(msg, SOL_IPV6, IPV6_RECVFRAGSIZE, sizeof(val), &val);
+ }
}
void ip6_datagram_recv_ctl(struct sock *sk, struct msghdr *msg,
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 636ec56..6c12678 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -868,6 +868,10 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
np->autoflowlabel = valbool;
retv = 0;
break;
+ case IPV6_RECVFRAGSIZE:
+ np->rxopt.bits.recvfragsize = valbool;
+ retv = 0;
+ break;
}
release_sock(sk);
@@ -1310,6 +1314,10 @@ static int do_ipv6_getsockopt(struct sock *sk, int level, int optname,
val = np->autoflowlabel;
break;
+ case IPV6_RECVFRAGSIZE:
+ val = np->rxopt.bits.recvfragsize;
+ break;
+
default:
return -ENOPROTOOPT;
}
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH net-next 0/3] ip: add RECVFRAGSIZE cmsg
From: Willem de Bruijn @ 2016-11-02 15:02 UTC (permalink / raw)
To: netdev; +Cc: jdorfman, eric.dumazet, davem, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
On IP datagrams and raw sockets, when packets arrive fragmented,
expose the largest received fragment size through a new cmsg.
Protocols implemented on top of these sockets may use this, for
instance, to inform peers to lower MSS on platforms that silently
allow send calls to exceed PMTU and cause fragmentation.
Willem de Bruijn (3):
ipv4: add IP_RECVFRAGSIZE cmsg
ipv6: add IPV6_RECVFRAGSIZE cmsg
ipv6: on reassembly, record frag_max_size
include/linux/ipv6.h | 5 +++--
include/net/inet_sock.h | 1 +
include/uapi/linux/in.h | 1 +
include/uapi/linux/in6.h | 1 +
net/ipv4/ip_sockglue.c | 26 ++++++++++++++++++++++++++
net/ipv6/datagram.c | 5 +++++
net/ipv6/ipv6_sockglue.c | 8 ++++++++
net/ipv6/reassembly.c | 7 ++++++-
8 files changed, 51 insertions(+), 3 deletions(-)
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply
* Re: [patch net-next 2/2] [PATCH] net: ip, raw_diag -- Use jump for exiting from nested loop
From: David Ahern @ 2016-11-02 14:56 UTC (permalink / raw)
To: Cyrill Gorcunov, netdev
Cc: Eric Dumazet, David S. Miller, Andrey Vagin, Stephen Hemminger
In-Reply-To: <20161102125454.754267793@openvz.org>
On 11/2/16 6:36 AM, Cyrill Gorcunov wrote:
> I managed to miss that sk_for_each is called under "for"
> cycle so need to use goto here to return matching socket.
>
> CC: David S. Miller <davem@davemloft.net>
> CC: Eric Dumazet <eric.dumazet@gmail.com>
> CC: David Ahern <dsa@cumulusnetworks.com>
> CC: Andrey Vagin <avagin@openvz.org>
> CC: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
> ---
> net/ipv4/raw_diag.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Acked-by: David Ahern <dsa@cumulusnetworks.com>
^ permalink raw reply
* Re: [patch net-next 1/2] [PATCH] net: ip, raw_diag -- Fix socket leaking for destroy request
From: David Ahern @ 2016-11-02 14:56 UTC (permalink / raw)
To: Cyrill Gorcunov, netdev
Cc: Eric Dumazet, David S. Miller, Andrey Vagin, Stephen Hemminger
In-Reply-To: <20161102125454.694582296@openvz.org>
On 11/2/16 6:36 AM, Cyrill Gorcunov wrote:
> In raw_diag_destroy the helper raw_sock_get returns
> with sock_hold call, so we have to put it then.
>
> CC: David S. Miller <davem@davemloft.net>
> CC: Eric Dumazet <eric.dumazet@gmail.com>
> CC: David Ahern <dsa@cumulusnetworks.com>
> CC: Andrey Vagin <avagin@openvz.org>
> CC: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
> ---
> net/ipv4/raw_diag.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
Acked-by: David Ahern <dsa@cumulusnetworks.com>
^ permalink raw reply
* [PATCH net] tcp: fix potential memory corruption
From: Eric Dumazet @ 2016-11-02 14:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Hans Westgaard Ry, Håkon Bugge
From: Eric Dumazet <edumazet@google.com>
Imagine initial value of max_skb_frags is 17, and last
skb in write queue has 15 frags.
Then max_skb_frags is lowered to 14 or smaller value.
tcp_sendmsg() will then be allowed to add additional page frags
and eventually go past MAX_SKB_FRAGS, overflowing struct
skb_shared_info.
Fixes: 5f74f82ea34c ("net:Add sysctl_max_skb_frags")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Hans Westgaard Ry <hans.westgaard.ry@oracle.com>
Cc: Håkon Bugge <haakon.bugge@oracle.com>
---
net/ipv4/tcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 3251fe71f39f..18238ef8135a 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1241,7 +1241,7 @@ int tcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
if (!skb_can_coalesce(skb, i, pfrag->page,
pfrag->offset)) {
- if (i == sysctl_max_skb_frags || !sg) {
+ if (i >= sysctl_max_skb_frags || !sg) {
tcp_mark_push(tp, skb);
goto new_segment;
}
^ permalink raw reply related
* Re: SNMP read-write MIBs
From: Murali Karicheri @ 2016-11-02 14:47 UTC (permalink / raw)
To: open list:TI NETCP ETHERNET DRIVER,
eric.dumazet@gmail.com >> Eric Dumazet, David Miller
In-Reply-To: <5818D9B0.60907@ti.com>
+ David, Eric,
On 11/01/2016 02:06 PM, Murali Karicheri wrote:
> Hello netdev experts,
>
> I am investigating the requirements to support hsr/prp SNMP functions in kernel.
> Based on my investigation so far, the kernel include file include/net/snmp.h
> defines all of the SNMP MIBS related defines and structures. But the MIBs are
> read-only type MIBs. Is there any implementation of read-write MIBs in kernel?
>
> One of the specs for MIBs that are investigating have read-write MIBs and
> wondering if we have any precedence of such MIBs implemented in kernel space.
> If not, what is the suggested way to implement these MIBs in kernel space?
>
> I assume that to implement read-only MIBs for hsr driver, I need to add
> them to snmp.h and use standard Macros in snmp.h to update them from the driver.
>
> Thanks
>
> Murali Karicheri
> Linux Kernel, Keystone
>
I did some more research on this, and found some of the (not sure if there is any
in kernel) read-write MIBs are implemented in the net-snmp, where
it communicate using a raw socket and calling an ioctl. Is this the way to go
to implement the read-write MIBs?
Thanks
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply
* Re: [PATCH net-next v2] ipv4: fib: Replay events when registering FIB notifier
From: Jiri Pirko @ 2016-11-02 14:43 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Ido Schimmel, Eric Dumazet, netdev@vger.kernel.org,
davem@davemloft.net, Jiri Pirko, mlxsw, David Ahern,
Nikolay Aleksandrov, Andy Gospodarek, Vivien Didelot, Andrew Lunn,
Florian Fainelli, alexander.h.duyck, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Ido Schimmel
In-Reply-To: <5819F997.2000808@cumulusnetworks.com>
Wed, Nov 02, 2016 at 03:35:03PM CET, roopa@cumulusnetworks.com wrote:
>On 11/2/16, 6:48 AM, Jiri Pirko wrote:
>> Wed, Nov 02, 2016 at 02:29:40PM CET, roopa@cumulusnetworks.com wrote:
>>> On Wed, Nov 2, 2016 at 12:20 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>>> Wed, Nov 02, 2016 at 03:13:42AM CET, roopa@cumulusnetworks.com wrote:
>>> [snip]
>>>
>>>>> I understand..but, if you are adding some core infrastructure for switchdev ..it cannot be
>>>>> based on the number of simple use-cases or data you have today.
>>>>>
>>>>> I won't be surprised if tomorrow other switch drivers have a case where they need to
>>>>> reset the hw routing table state and reprogram all routes again. Re-registering the notifier to just
>>>>> get the routing state of the kernel will not scale. For the long term, since the driver does not maintain a cache,
>>>> Driver (mlxsw, rocker) maintain a cache. So I'm not sure why you say
>>>> otherwise.
>>>>
>>>>
>>>>> a pull api with efficient use of rtnl will be useful for other such cases as well.
>>>> How do you imagine this "pull API" should look like?
>>>
>>> Just like you already have added fib notifiers to parallel fib netlink
>>> notifications, the pull API is a parallel to 'netlink dump'.
>>> Is my imagination too wild ? :)
>> Perhaps I'm slow, but I don't understand what you mean.
>
>>>>>
>>>>> If you don't want to get to the complexity of a new api right away because of the
>>>>> simple case of management interface routes you have, Can your driver register the notifier early ?
>>>>> (I am sure you have probably already thought about this)
>>>> Register early? What it would resolve? I must be missing something. We
>>>> register as early as possible. But the thing is, we cannot register
>>>> in a past. And that is what this patch resolves.
>>> sure, you must be having a valid problem then. I was just curious why
>>> your driver is not up and initialized before any of the addresses or
>>> routes get configured in the system (even on a management port). Ours
>> If you unload the module and load it again for example. This is a valid
>> usecase.
>
>I see, so you are optimizing for this use case. sure it is a valid use-case but a narrow one
It is not an optimization, it's a bug fix.
>compared to the rtnl overhead the api may bring
> (note that i am not saying you should not solve it).
>
>>
>>
>>> does. But i agree there can be races and you cannot always guarantee
>>> (I was just responding to ido's comment about adding complexity for a
>>> small problem he has to solve for management routes). Our driver does
>>> a pull before it starts. This helps when we want to reset the hardware
>>> routing table state too.
>> Can you point me to you driver in the tree? I would like to see how you
>> do "the pull".
>:), you know all this... but, if i must explicitly say it, yes, we don't have a driver in the tree and
>we don't own the hardware. My analogy here is of a netlink dump that we use heavily for the
>same scale that you will probably deploy.
You are comparing netlink kernel-user api with in kernel api. I don't
think that is comparable, at all. Therefore I asked how you imagine
"the pull" should look like, in kernel. Stating it should look like
some user api part does not help me much :(
>i do give you full credit for the hardware and the driver and switchdev support and all that!.
>
>>
>>>
>>> But, my point was, when you are defining an API, you cannot quantify
>>> the 'past' to be just the very 'close past' or 'the past is just the
>>> management routes that were added' . Tomorrow the 'past' can be the
>>> full routing table if you need to reset the hardware state.
>> Sure.
>
>This pull api was a suggestion for an efficient use of rtnl ...similar to how the netlink
>routing dump handles it. If you cannot imagine an api like that..., sure, your call.
No, that's why I'm asking, because I was under impression you can
imagine that :)
^ permalink raw reply
* [PATCH net] qede: Correctly map aggregation replacement pages
From: Yuval Mintz @ 2016-11-02 14:36 UTC (permalink / raw)
To: davem, netdev; +Cc: Yuval Mintz
Driver allocates replacement buffers before-hand to make
sure whenever an aggregation begins there would be a replacement
for the Rx buffers, as we can't release the buffer until
aggregation is terminated and driver logic assumes the Rx rings
are always full.
For every other Rx page that's being allocated [I.e., regular]
the page is being completely mapped while for the replacement
buffers only the first portion of the page is being mapped.
This means that:
a. Once replacement buffer replenishes the regular Rx ring,
assuming there's more than a single packet on page we'd post unmapped
memory toward HW [assuming mapping is actually done in granularity
smaller than page].
b. Unmaps are being done for the entire page, which is incorrect.
Fixes: 55482edc25f06 ("qede: Add slowpath/fastpath support and enable hardware GRO")
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
---
Dave,
Please consider applying this to `net'.
Thanks,
Yuval
---
drivers/net/ethernet/qlogic/qede/qede_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_main.c b/drivers/net/ethernet/qlogic/qede/qede_main.c
index 1391776..73f2a67 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_main.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_main.c
@@ -2918,7 +2918,7 @@ static int qede_alloc_sge_mem(struct qede_dev *edev, struct qede_rx_queue *rxq)
}
mapping = dma_map_page(&edev->pdev->dev, replace_buf->data, 0,
- rxq->rx_buf_size, DMA_FROM_DEVICE);
+ PAGE_SIZE, DMA_FROM_DEVICE);
if (unlikely(dma_mapping_error(&edev->pdev->dev, mapping))) {
DP_NOTICE(edev,
"Failed to map TPA replacement buffer\n");
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next v2] ipv4: fib: Replay events when registering FIB notifier
From: Roopa Prabhu @ 2016-11-02 14:35 UTC (permalink / raw)
To: Jiri Pirko
Cc: Ido Schimmel, Eric Dumazet, netdev@vger.kernel.org,
davem@davemloft.net, Jiri Pirko, mlxsw, David Ahern,
Nikolay Aleksandrov, Andy Gospodarek, Vivien Didelot, Andrew Lunn,
Florian Fainelli, alexander.h.duyck, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Ido Schimmel
In-Reply-To: <20161102134845.GI1713@nanopsycho.orion>
On 11/2/16, 6:48 AM, Jiri Pirko wrote:
> Wed, Nov 02, 2016 at 02:29:40PM CET, roopa@cumulusnetworks.com wrote:
>> On Wed, Nov 2, 2016 at 12:20 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>> Wed, Nov 02, 2016 at 03:13:42AM CET, roopa@cumulusnetworks.com wrote:
>> [snip]
>>
>>>> I understand..but, if you are adding some core infrastructure for switchdev ..it cannot be
>>>> based on the number of simple use-cases or data you have today.
>>>>
>>>> I won't be surprised if tomorrow other switch drivers have a case where they need to
>>>> reset the hw routing table state and reprogram all routes again. Re-registering the notifier to just
>>>> get the routing state of the kernel will not scale. For the long term, since the driver does not maintain a cache,
>>> Driver (mlxsw, rocker) maintain a cache. So I'm not sure why you say
>>> otherwise.
>>>
>>>
>>>> a pull api with efficient use of rtnl will be useful for other such cases as well.
>>> How do you imagine this "pull API" should look like?
>>
>> Just like you already have added fib notifiers to parallel fib netlink
>> notifications, the pull API is a parallel to 'netlink dump'.
>> Is my imagination too wild ? :)
> Perhaps I'm slow, but I don't understand what you mean.
>>>>
>>>> If you don't want to get to the complexity of a new api right away because of the
>>>> simple case of management interface routes you have, Can your driver register the notifier early ?
>>>> (I am sure you have probably already thought about this)
>>> Register early? What it would resolve? I must be missing something. We
>>> register as early as possible. But the thing is, we cannot register
>>> in a past. And that is what this patch resolves.
>> sure, you must be having a valid problem then. I was just curious why
>> your driver is not up and initialized before any of the addresses or
>> routes get configured in the system (even on a management port). Ours
> If you unload the module and load it again for example. This is a valid
> usecase.
I see, so you are optimizing for this use case. sure it is a valid use-case but a narrow one
compared to the rtnl overhead the api may bring
(note that i am not saying you should not solve it).
>
>
>> does. But i agree there can be races and you cannot always guarantee
>> (I was just responding to ido's comment about adding complexity for a
>> small problem he has to solve for management routes). Our driver does
>> a pull before it starts. This helps when we want to reset the hardware
>> routing table state too.
> Can you point me to you driver in the tree? I would like to see how you
> do "the pull".
:), you know all this... but, if i must explicitly say it, yes, we don't have a driver in the tree and
we don't own the hardware. My analogy here is of a netlink dump that we use heavily for the
same scale that you will probably deploy.
i do give you full credit for the hardware and the driver and switchdev support and all that!.
>
>>
>> But, my point was, when you are defining an API, you cannot quantify
>> the 'past' to be just the very 'close past' or 'the past is just the
>> management routes that were added' . Tomorrow the 'past' can be the
>> full routing table if you need to reset the hardware state.
> Sure.
This pull api was a suggestion for an efficient use of rtnl ...similar to how the netlink
routing dump handles it. If you cannot imagine an api like that..., sure, your call.
^ permalink raw reply
* Re: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net
From: Jesper Dangaard Brouer @ 2016-11-02 14:27 UTC (permalink / raw)
To: Thomas Graf
Cc: Shrijeet Mukherjee, Alexei Starovoitov, Jakub Kicinski,
John Fastabend, David Miller, alexander.duyck, mst, shrijeet, tom,
netdev, Roopa Prabhu, Nikolay Aleksandrov, brouer
In-Reply-To: <20161029112514.GC1810@pox.localdomain>
On Sat, 29 Oct 2016 13:25:14 +0200
Thomas Graf <tgraf@suug.ch> wrote:
> On 10/28/16 at 08:51pm, Shrijeet Mukherjee wrote:
> > Generally agree, but SRIOV nics with multiple queues can end up in a bad
> > spot if each buffer was 4K right ? I see a specific page pool to be used
> > by queues which are enabled for XDP as the easiest to swing solution that
> > way the memory overhead can be restricted to enabled queues and shared
> > access issues can be restricted to skb's using that pool no ?
Yes, that is why that I've been arguing so strongly for having the
flexibility to attach a XDP program per RX queue, as this only change
the memory model for this one queue.
> Isn't this clearly a must anyway? I may be missing something
> fundamental here so please enlighten me :-)
>
> If we dedicate a page per packet, that could translate to 14M*4K worth
> of memory being mapped per second for just a 10G NIC under DoS attack.
> How can one protect such as system? Is the assumption that we can always
> drop such packets quickly enough before we start dropping randomly due
> to memory pressure? If a handshake is required to determine validity
> of a packet then that is going to be difficult.
Under DoS attacks you don't run out of memory, because a diverse set of
socket memory limits/accounting avoids that situation. What does
happen is the maximum achievable PPS rate is directly dependent on the
time you spend on each packet. This use of CPU resources (and
hitting mem-limits-safe-guards) push-back on the drivers speed to
process the RX ring. In effect, packets are dropped in the NIC HW as
RX-ring queue is not emptied fast-enough.
Given you don't control what HW drops, the attacker will "successfully"
cause your good traffic to be among the dropped packets.
This is where XDP change the picture. If you can express (by eBPF) a
filter that can separate "bad" vs "good" traffic, then you can take
back control. Almost like controlling what traffic the HW should drop.
Given the cost of XDP-eBPF filter + serving regular traffic does not
use all of your CPU resources, you have overcome the attack.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH] igb: Workaround for igb i210 firmware issue.
From: Chris J Arges @ 2016-11-02 14:13 UTC (permalink / raw)
To: jh; +Cc: intel-wired-lan, Chris J Arges, Jeff Kirsher, netdev,
linux-kernel
Sometimes firmware may not properly initialize I347AT4_PAGE_SELECT causing
the probe of an igb i210 NIC to fail. This patch adds an addition zeroing of
this register during igb_get_phy_id to workaround this issue.
Thanks for Jochen Henneberg for the idea and original patch.
Signed-off-by: Chris J Arges <christopherarges@gmail.com>
---
drivers/net/ethernet/intel/igb/e1000_phy.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/intel/igb/e1000_phy.c b/drivers/net/ethernet/intel/igb/e1000_phy.c
index 5b54254..93ec2d0 100644
--- a/drivers/net/ethernet/intel/igb/e1000_phy.c
+++ b/drivers/net/ethernet/intel/igb/e1000_phy.c
@@ -77,6 +77,10 @@ s32 igb_get_phy_id(struct e1000_hw *hw)
s32 ret_val = 0;
u16 phy_id;
+ /* ensure phy page selection to fix misconfigured i210 */
+ if (hw->mac.type == e1000_i210)
+ phy->ops.write_reg(hw, I347AT4_PAGE_SELECT, 0);
+
ret_val = phy->ops.read_reg(hw, PHY_ID1, &phy_id);
if (ret_val)
goto out;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next 3/3] tools lib bpf: Sync bpf_map_def with tc
From: Daniel Borkmann @ 2016-11-02 14:12 UTC (permalink / raw)
To: Joe Stringer; +Cc: netdev, wangnan0, ast
In-Reply-To: <CAPWQB7GxA+imikeJEJ-JZVm+qWONM1Ronj7ucf0=QRBbrPM06g@mail.gmail.com>
On 11/02/2016 05:09 AM, Joe Stringer wrote:
> On 1 November 2016 at 20:09, Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On 10/31/2016 07:39 PM, Joe Stringer wrote:
>>>
>>> TC uses a slightly different map layout in its ELFs. Update libbpf to
>>> use the same definition so that ELFs may be built using libbpf and
>>> loaded using tc.
>>>
>>> Signed-off-by: Joe Stringer <joe@ovn.org>
>>> ---
>>> tools/lib/bpf/libbpf.h | 11 +++++++----
>>> 1 file changed, 7 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
>>> index dd7a513efb10..ea70c2744f8c 100644
>>> --- a/tools/lib/bpf/libbpf.h
>>> +++ b/tools/lib/bpf/libbpf.h
>>> @@ -181,10 +181,13 @@ bool bpf_program__is_kprobe(struct bpf_program
>>> *prog);
>>> * and will be treated as an error due to -Werror.
>>> */
>>> struct bpf_map_def {
>>> - unsigned int type;
>>> - unsigned int key_size;
>>> - unsigned int value_size;
>>> - unsigned int max_entries;
>>> + uint32_t type;
>>> + uint32_t key_size;
>>> + uint32_t value_size;
>>> + uint32_t max_entries;
>>> + uint32_t flags;
>>> + uint32_t id;
>>> + uint32_t pinning;
>>> };
>>>
>>> /*
>>
>> I think the problem is that this would break existing obj files that have
>> been compiled with the current struct bpf_map_def (besides libbpf not having
>> a use for the last two members right now).
>
> Right, this is a problem. I wasn't sure whether libbpf was yet at a
> stage where it tries to retain compatibility with binaries compiled
> against older kernels.
>
>> For tc, we have a refactoring of the tc_bpf.c bits that generalizes them so
>> we can move these bits into iproute2 lib part and add new BPF types really
>> easily. What I did along with that is to implement a map compat mode, where
>> it detects the size of struct bpf_elf_map (or however you want to name it)
>> from the obj file and fixes up the missing members with some reasonable
>> default,
>> so these programs can still be loaded. Thus, the sample code using the
>> current
>> struct bpf_map_def will then work with tc as well. (I'll post the iproute2
>> patch early next week.)
>
> Are you encoding the number of maps into the start of the maps section
> in the ELF then using that to divide out and determine the size?
No. It's walking the symbol table and simply counts the number of symbols
that are present in the maps section with correct st_info attribution. It
works because that section name is fixed ABI for all cases and really per
definition only map structs are present there. The minimum attributes which
are allowed to be loaded are type, key_size, value_size and max_entries.
> I look forward to your patches. Maybe if TC is more tolerant of other
> map definition sizes then this patch is less relevant.
^ permalink raw reply
* [PATCH v3 2/2] dt-bindings: net: Add OXNAS DWMAC Bindings
From: Neil Armstrong @ 2016-11-02 14:02 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue
Cc: Neil Armstrong, netdev, linux-oxnas, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <20161102140237.6955-1-narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../devicetree/bindings/net/oxnas-dwmac.txt | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
diff --git a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
new file mode 100644
index 0000000..df0534e
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
@@ -0,0 +1,39 @@
+* Oxford Semiconductor OXNAS DWMAC Ethernet controller
+
+The device inherits all the properties of the dwmac/stmmac devices
+described in the file stmmac.txt in the current directory with the
+following changes.
+
+Required properties on all platforms:
+
+- compatible: For the OX820 SoC, it should be :
+ - "oxsemi,ox820-dwmac" to select glue
+ - "snps,dwmac-3.512" to select IP version.
+
+- clocks: Should contain phandles to the following clocks
+- clock-names: Should contain the following:
+ - "stmmaceth" for the host clock - see stmmac.txt
+ - "gmac" for the peripheral gate clock
+
+- oxsemi,sys-ctrl: a phandle to the system controller syscon node
+
+Example :
+
+etha: ethernet@40400000 {
+ compatible = "oxsemi,ox820-dwmac", "snps,dwmac-3.512";
+ reg = <0x40400000 0x2000>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq", "eth_wake_irq";
+ mac-address = [000000000000]; /* Filled in by U-Boot */
+ phy-mode = "rgmii";
+
+ clocks = <&stdclk CLK_820_ETHA>, <&gmacclk>;
+ clock-names = "gmac", "stmmaceth";
+ resets = <&reset RESET_MAC>;
+
+ /* Regmap for sys registers */
+ oxsemi,sys-ctrl = <&sys>;
+
+ status = "disabled";
+};
--
2.7.0
^ permalink raw reply related
* [PATCH v3 1/2] net: stmmac: Add OXNAS Glue Driver
From: Neil Armstrong @ 2016-11-02 14:02 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue
Cc: Neil Armstrong, netdev, linux-oxnas, linux-arm-kernel,
linux-kernel
In-Reply-To: <20161102140237.6955-1-narmstrong@baylibre.com>
Add Synopsys Designware MAC Glue layer for the Oxford Semiconductor OX820.
Acked-by: Joachim Eastwood <manabian@gmail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 217 ++++++++++++++++++++++
3 files changed, 229 insertions(+)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 3818c5e..6e9fcc3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -69,6 +69,17 @@ config DWMAC_MESON
the stmmac device driver. This driver is used for Meson6,
Meson8, Meson8b and GXBB SoCs.
+config DWMAC_OXNAS
+ tristate "Oxford Semiconductor OXNAS dwmac support"
+ default ARCH_OXNAS
+ depends on OF && COMMON_CLK && (ARCH_OXNAS || COMPILE_TEST)
+ select MFD_SYSCON
+ help
+ Support for Ethernet controller on Oxford Semiconductor OXNAS SoCs.
+
+ This selects the Oxford Semiconductor OXNASSoC glue layer support for
+ the stmmac device driver. This driver is used for OX820.
+
config DWMAC_ROCKCHIP
tristate "Rockchip dwmac support"
default ARCH_ROCKCHIP
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 5d6ece5..8f83a86 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_STMMAC_PLATFORM) += stmmac-platform.o
obj-$(CONFIG_DWMAC_IPQ806X) += dwmac-ipq806x.o
obj-$(CONFIG_DWMAC_LPC18XX) += dwmac-lpc18xx.o
obj-$(CONFIG_DWMAC_MESON) += dwmac-meson.o dwmac-meson8b.o
+obj-$(CONFIG_DWMAC_OXNAS) += dwmac-oxnas.o
obj-$(CONFIG_DWMAC_ROCKCHIP) += dwmac-rk.o
obj-$(CONFIG_DWMAC_SOCFPGA) += dwmac-altr-socfpga.o
obj-$(CONFIG_DWMAC_STI) += dwmac-sti.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
new file mode 100644
index 0000000..c355975
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
@@ -0,0 +1,217 @@
+/*
+ * Oxford Semiconductor OXNAS DWMAC glue layer
+ *
+ * Copyright (C) 2016 Neil Armstrong <narmstrong@baylibre.com>
+ * Copyright (C) 2014 Daniel Golle <daniel@makrotopia.org>
+ * Copyright (C) 2013 Ma Haijun <mahaijuns@gmail.com>
+ * Copyright (C) 2012 John Crispin <blogic@openwrt.org>
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+#include <linux/stmmac.h>
+
+#include "stmmac_platform.h"
+
+/* System Control regmap offsets */
+#define OXNAS_DWMAC_CTRL_REGOFFSET 0x78
+#define OXNAS_DWMAC_DELAY_REGOFFSET 0x100
+
+/* Control Register */
+#define DWMAC_CKEN_RX_IN 14
+#define DWMAC_CKEN_RXN_OUT 13
+#define DWMAC_CKEN_RX_OUT 12
+#define DWMAC_CKEN_TX_IN 10
+#define DWMAC_CKEN_TXN_OUT 9
+#define DWMAC_CKEN_TX_OUT 8
+#define DWMAC_RX_SOURCE 7
+#define DWMAC_TX_SOURCE 6
+#define DWMAC_LOW_TX_SOURCE 4
+#define DWMAC_AUTO_TX_SOURCE 3
+#define DWMAC_RGMII 2
+#define DWMAC_SIMPLE_MUX 1
+#define DWMAC_CKEN_GTX 0
+
+/* Delay register */
+#define DWMAC_TX_VARDELAY_SHIFT 0
+#define DWMAC_TXN_VARDELAY_SHIFT 8
+#define DWMAC_RX_VARDELAY_SHIFT 16
+#define DWMAC_RXN_VARDELAY_SHIFT 24
+#define DWMAC_TX_VARDELAY(d) ((d) << DWMAC_TX_VARDELAY_SHIFT)
+#define DWMAC_TXN_VARDELAY(d) ((d) << DWMAC_TXN_VARDELAY_SHIFT)
+#define DWMAC_RX_VARDELAY(d) ((d) << DWMAC_RX_VARDELAY_SHIFT)
+#define DWMAC_RXN_VARDELAY(d) ((d) << DWMAC_RXN_VARDELAY_SHIFT)
+
+struct oxnas_dwmac {
+ struct device *dev;
+ struct clk *clk;
+ struct regmap *regmap;
+};
+
+static int oxnas_dwmac_init(struct oxnas_dwmac *dwmac)
+{
+ unsigned int value;
+ int ret;
+
+ /* Reset HW here before changing the glue configuration */
+ ret = device_reset(dwmac->dev);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(dwmac->clk);
+ if (ret)
+ return ret;
+
+ ret = regmap_read(dwmac->regmap, OXNAS_DWMAC_CTRL_REGOFFSET, &value);
+ if (ret < 0) {
+ clk_disable_unprepare(dwmac->clk);
+ return ret;
+ }
+
+ /* Enable GMII_GTXCLK to follow GMII_REFCLK, required for gigabit PHY */
+ value |= BIT(DWMAC_CKEN_GTX) |
+ /* Use simple mux for 25/125 Mhz clock switching */
+ BIT(DWMAC_SIMPLE_MUX) |
+ /* set auto switch tx clock source */
+ BIT(DWMAC_AUTO_TX_SOURCE) |
+ /* enable tx & rx vardelay */
+ BIT(DWMAC_CKEN_TX_OUT) |
+ BIT(DWMAC_CKEN_TXN_OUT) |
+ BIT(DWMAC_CKEN_TX_IN) |
+ BIT(DWMAC_CKEN_RX_OUT) |
+ BIT(DWMAC_CKEN_RXN_OUT) |
+ BIT(DWMAC_CKEN_RX_IN);
+ regmap_write(dwmac->regmap, OXNAS_DWMAC_CTRL_REGOFFSET, value);
+
+ /* set tx & rx vardelay */
+ value = DWMAC_TX_VARDELAY(4) |
+ DWMAC_TXN_VARDELAY(2) |
+ DWMAC_RX_VARDELAY(10) |
+ DWMAC_RXN_VARDELAY(8);
+ regmap_write(dwmac->regmap, OXNAS_DWMAC_DELAY_REGOFFSET, value);
+
+ return 0;
+}
+
+static int oxnas_dwmac_probe(struct platform_device *pdev)
+{
+ struct plat_stmmacenet_data *plat_dat;
+ struct stmmac_resources stmmac_res;
+ struct device_node *sysctrl;
+ struct oxnas_dwmac *dwmac;
+ int ret;
+
+ sysctrl = of_parse_phandle(pdev->dev.of_node, "oxsemi,sys-ctrl", 0);
+ if (!sysctrl) {
+ dev_err(&pdev->dev, "failed to get sys-ctrl node\n");
+ return -EINVAL;
+ }
+
+ ret = stmmac_get_platform_resources(pdev, &stmmac_res);
+ if (ret)
+ return ret;
+
+ plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
+ if (IS_ERR(plat_dat))
+ return PTR_ERR(plat_dat);
+
+ dwmac = devm_kzalloc(&pdev->dev, sizeof(*dwmac), GFP_KERNEL);
+ if (!dwmac)
+ return -ENOMEM;
+
+ dwmac->dev = &pdev->dev;
+ plat_dat->bsp_priv = dwmac;
+
+ dwmac->regmap = syscon_node_to_regmap(sysctrl);
+ if (IS_ERR(dwmac->regmap)) {
+ dev_err(&pdev->dev, "failed to have sysctrl regmap\n");
+ return PTR_ERR(dwmac->regmap);
+ }
+
+ dwmac->clk = devm_clk_get(&pdev->dev, "gmac");
+ if (IS_ERR(dwmac->clk))
+ return PTR_ERR(dwmac->clk);
+
+ ret = oxnas_dwmac_init(dwmac);
+ if (ret)
+ return ret;
+
+ ret = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
+ if (ret)
+ clk_disable_unprepare(dwmac->clk);
+
+ return ret;
+}
+
+static int oxnas_dwmac_remove(struct platform_device *pdev)
+{
+ struct oxnas_dwmac *dwmac = get_stmmac_bsp_priv(&pdev->dev);
+ int ret = stmmac_dvr_remove(&pdev->dev);
+
+ clk_disable_unprepare(dwmac->clk);
+
+ return ret;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int oxnas_dwmac_suspend(struct device *dev)
+{
+ struct oxnas_dwmac *dwmac = get_stmmac_bsp_priv(dev);
+ int ret;
+
+ ret = stmmac_suspend(dev);
+ clk_disable_unprepare(dwmac->clk);
+
+ return ret;
+}
+
+static int oxnas_dwmac_resume(struct device *dev)
+{
+ struct oxnas_dwmac *dwmac = get_stmmac_bsp_priv(dev);
+ int ret;
+
+ ret = oxnas_dwmac_init(dwmac);
+ if (ret)
+ return ret;
+
+ ret = stmmac_resume(dev);
+
+ return ret;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static SIMPLE_DEV_PM_OPS(oxnas_dwmac_pm_ops,
+ oxnas_dwmac_suspend, oxnas_dwmac_resume);
+
+static const struct of_device_id oxnas_dwmac_match[] = {
+ { .compatible = "oxsemi,ox820-dwmac" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, oxnas_dwmac_match);
+
+static struct platform_driver oxnas_dwmac_driver = {
+ .probe = oxnas_dwmac_probe,
+ .remove = oxnas_dwmac_remove,
+ .driver = {
+ .name = "oxnas-dwmac",
+ .pm = &oxnas_dwmac_pm_ops,
+ .of_match_table = oxnas_dwmac_match,
+ },
+};
+module_platform_driver(oxnas_dwmac_driver);
+
+MODULE_AUTHOR("Neil Armstrong <narmstrong@baylibre.com>");
+MODULE_DESCRIPTION("Oxford Semiconductor OXNAS DWMAC glue layer");
+MODULE_LICENSE("GPL v2");
--
2.7.0
^ permalink raw reply related
* [PATCH v3 0/2] net: stmmac: Add OXNAS DWMAC Glue
From: Neil Armstrong @ 2016-11-02 14:02 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue
Cc: Neil Armstrong, netdev, linux-oxnas, linux-arm-kernel,
linux-kernel
This patchset add support for the Sysnopsys DWMAC Gigabit Ethernet
controller Glue layer of the Oxford Semiconductor OX820 SoC.
Changes since v2 at http://lkml.kernel.org/r/20161031105345.16711-1-narmstrong@baylibre.com :
- Disable/Unprepare clock if regmap read fails in oxnas_dwmac_init
Changes since v1 at https://patchwork.kernel.org/patch/9388231/ :
- Split dt-bindings in a separate patch
- Add IP version in the dt-bindings compatible
- Check return of clk_prepare_enable()
- use get_stmmac_bsp_priv() helper
- hardwire setup values in oxnas_dwmac_init()
Changes since RFC at https://patchwork.kernel.org/patch/9387257 :
- Drop init/exit callbacks
- Implement proper remove and PM callback
- Call init from probe
- Disable/Unprepare clock if stmmac probe fails
Neil Armstrong (2):
net: stmmac: Add OXNAS Glue Driver
dt-bindings: net: Add OXNAS DWMAC Bindings
.../devicetree/bindings/net/oxnas-dwmac.txt | 39 ++++
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 217 +++++++++++++++++++++
4 files changed, 268 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
--
2.7.0
^ permalink raw reply
* Re: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net
From: Jesper Dangaard Brouer @ 2016-11-02 14:01 UTC (permalink / raw)
To: David Miller
Cc: john.fastabend, alexander.duyck, mst, shrijeet, tom, netdev, shm,
roopa, nikolay, brouer
In-Reply-To: <20161028.131101.1982236040609043994.davem@davemloft.net>
On Fri, 28 Oct 2016 13:11:01 -0400 (EDT)
David Miller <davem@davemloft.net> wrote:
> From: John Fastabend <john.fastabend@gmail.com>
> Date: Fri, 28 Oct 2016 08:56:35 -0700
>
> > On 16-10-27 07:10 PM, David Miller wrote:
> >> From: Alexander Duyck <alexander.duyck@gmail.com>
> >> Date: Thu, 27 Oct 2016 18:43:59 -0700
> >>
> >>> On Thu, Oct 27, 2016 at 6:35 PM, David Miller <davem@davemloft.net> wrote:
> >>>> From: "Michael S. Tsirkin" <mst@redhat.com>
> >>>> Date: Fri, 28 Oct 2016 01:25:48 +0300
> >>>>
> >>>>> On Thu, Oct 27, 2016 at 05:42:18PM -0400, David Miller wrote:
> >>>>>> From: "Michael S. Tsirkin" <mst@redhat.com>
> >>>>>> Date: Fri, 28 Oct 2016 00:30:35 +0300
> >>>>>>
> >>>>>>> Something I'd like to understand is how does XDP address the
> >>>>>>> problem that 100Byte packets are consuming 4K of memory now.
> >>>>>>
> >>>>>> Via page pools. We're going to make a generic one, but right now
> >>>>>> each and every driver implements a quick list of pages to allocate
> >>>>>> from (and thus avoid the DMA man/unmap overhead, etc.)
> >>>>>
> >>>>> So to clarify, ATM virtio doesn't attempt to avoid dma map/unmap
> >>>>> so there should be no issue with that even when using sub/page
> >>>>> regions, assuming DMA APIs support sub-page map/unmap correctly.
> >>>>
> >>>> That's not what I said.
> >>>>
> >>>> The page pools are meant to address the performance degradation from
> >>>> going to having one packet per page for the sake of XDP's
> >>>> requirements.
> >>>>
> >>>> You still need to have one packet per page for correct XDP operation
> >>>> whether you do page pools or not, and whether you have DMA mapping
> >>>> (or it's equivalent virutalization operation) or not.
> >>>
> >>> Maybe I am missing something here, but why do you need to limit things
> >>> to one packet per page for correct XDP operation? Most of the drivers
> >>> out there now are usually storing something closer to at least 2
> >>> packets per page, and with the DMA API fixes I am working on there
> >>> should be no issue with changing the contents inside those pages since
> >>> we won't invalidate or overwrite the data after the DMA buffer has
> >>> been synchronized for use by the CPU.
> >>
> >> Because with SKB's you can share the page with other packets.
> >>
> >> With XDP you simply cannot.
> >>
> >> It's software semantics that are the issue. SKB frag list pages
> >> are read only, XDP packets are writable.
> >>
> >> This has nothing to do with "writability" of the pages wrt. DMA
> >> mapping or cpu mappings.
> >>
> >
> > Sorry I'm not seeing it either. The current xdp_buff is defined
> > by,
> >
> > struct xdp_buff {
> > void *data;
> > void *data_end;
> > };
> >
> > The verifier has an xdp_is_valid_access() check to ensure we don't go
> > past data_end. The page for now at least never leaves the driver. For
> > the work to get xmit to other devices working I'm still not sure I see
> > any issue.
>
> I guess I can say that the packets must be "writable" until I'm blue
> in the face but I'll say it again, semantically writable pages are a
> requirement. And if multiple packets share a page this requirement
> is not satisfied.
>
> Also, we want to do several things in the future:
>
> 1) Allow push/pop of headers via eBPF code, which needs we need
> headroom.
>
> 2) Transparently zero-copy pass packets into userspace, basically
> the user will have a semi-permanently mapped ring of all the
> packet pages sitting in the RX queue of the device and the
> page pool associated with it. This way we avoid all of the
> TLB flush/map overhead for the user's mapping of the packets
> just as we avoid the DMA map/unmap overhead.
>
> And that's just the beginninng.
>
> I'm sure others can come up with more reasons why we have this
> requirement.
I've tried to update the XDP documentation about the "Page per packet"
requirement[1], fell free to correct below text:
Page per packet
===============
On RX many NIC drivers splitup a memory page, to share it for multiple
packets, in-order to conserve memory. Doing so complicates handling
and accounting of these memory pages, which affects performance.
Particularly the extra atomic refcnt handling needed for the page can
hurt performance.
XDP defines upfront a memory model where there is only one packet per
page. This simplifies page handling and open up for future
extensions.
This requirement also (upfront) result in choosing not to support
things like, jumpo-frames, LRO and generally packets split over
multiple pages.
In the future, this strict memory model might be relaxed, but for now
it is a strict requirement. With a more flexible
:ref:`ref_prog_negotiation` is might be possible to negotiate another
memory model. Given some specific XDP use-case might not require this
strict memory model.
Online here:
[1] http://prototype-kernel.readthedocs.io/en/latest/networking/XDP/design/requirements.html#page-per-packet
Commit:
https://github.com/netoptimizer/prototype-kernel/commit/27ece059011e6d5c8a1cb4bdb2ab361cd7faa6dd
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH v2 1/2] net: stmmac: Add OXNAS Glue Driver
From: Neil Armstrong @ 2016-11-02 13:54 UTC (permalink / raw)
To: Joachim Eastwood
Cc: peppe.cavallaro, alexandre.torgue, netdev, linux-oxnas,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAGhQ9VyAaqUy06kb_Mxewo+BbJnxe=e6=x8pFsVSY0Z6C-h=cg@mail.gmail.com>
On 10/31/2016 12:12 PM, Joachim Eastwood wrote:
> Hi Neil,
>
> On 31 October 2016 at 11:54, Neil Armstrong <narmstrong@baylibre.com> wrote:
>> Add Synopsys Designware MAC Glue layer for the Oxford Semiconductor OX820.
>>
>> Acked-by: Joachim Eastwood <manabian@gmail.com>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> +static int oxnas_dwmac_init(struct oxnas_dwmac *dwmac)
>> +{
>> + unsigned int value;
>> + int ret;
>> +
>> + /* Reset HW here before changing the glue configuration */
>> + ret = device_reset(dwmac->dev);
>> + if (ret)
>> + return ret;
>> +
>> + ret = clk_prepare_enable(dwmac->clk);
>> + if (ret)
>> + return ret;
>> +
>> + ret = regmap_read(dwmac->regmap, OXNAS_DWMAC_CTRL_REGOFFSET, &value);
>> + if (ret < 0)
>> + return ret;
>
> If regmap reading fails here, the clock will be left on as probe fails.
>
Indeed, thanks.
Neil
[...]
>
>
> regards,
> Joachim Eastwood
>
^ permalink raw reply
* Re: [PATCH net-next v2] ipv4: fib: Replay events when registering FIB notifier
From: Jiri Pirko @ 2016-11-02 13:48 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Ido Schimmel, Eric Dumazet, netdev@vger.kernel.org,
davem@davemloft.net, Jiri Pirko, mlxsw, David Ahern,
Nikolay Aleksandrov, Andy Gospodarek, Vivien Didelot, Andrew Lunn,
Florian Fainelli, alexander.h.duyck, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Ido Schimmel
In-Reply-To: <CAJieiUjGHX0C7mG3Y8m2VZHPPq=Rz-2D8e_L9ZASi-bCs8nJJw@mail.gmail.com>
Wed, Nov 02, 2016 at 02:29:40PM CET, roopa@cumulusnetworks.com wrote:
>On Wed, Nov 2, 2016 at 12:20 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Wed, Nov 02, 2016 at 03:13:42AM CET, roopa@cumulusnetworks.com wrote:
>>>
>[snip]
>
>>>I understand..but, if you are adding some core infrastructure for switchdev ..it cannot be
>>>based on the number of simple use-cases or data you have today.
>>>
>>>I won't be surprised if tomorrow other switch drivers have a case where they need to
>>>reset the hw routing table state and reprogram all routes again. Re-registering the notifier to just
>>>get the routing state of the kernel will not scale. For the long term, since the driver does not maintain a cache,
>>
>> Driver (mlxsw, rocker) maintain a cache. So I'm not sure why you say
>> otherwise.
>>
>>
>>>a pull api with efficient use of rtnl will be useful for other such cases as well.
>>
>> How do you imagine this "pull API" should look like?
>
>
>Just like you already have added fib notifiers to parallel fib netlink
>notifications, the pull API is a parallel to 'netlink dump'.
>Is my imagination too wild ? :)
Perhaps I'm slow, but I don't understand what you mean.
>
>
>>
>>
>>>
>>>
>>>If you don't want to get to the complexity of a new api right away because of the
>>>simple case of management interface routes you have, Can your driver register the notifier early ?
>>>(I am sure you have probably already thought about this)
>>
>> Register early? What it would resolve? I must be missing something. We
>> register as early as possible. But the thing is, we cannot register
>> in a past. And that is what this patch resolves.
>
>sure, you must be having a valid problem then. I was just curious why
>your driver is not up and initialized before any of the addresses or
>routes get configured in the system (even on a management port). Ours
If you unload the module and load it again for example. This is a valid
usecase.
>does. But i agree there can be races and you cannot always guarantee
>(I was just responding to ido's comment about adding complexity for a
>small problem he has to solve for management routes). Our driver does
>a pull before it starts. This helps when we want to reset the hardware
>routing table state too.
Can you point me to you driver in the tree? I would like to see how you
do "the pull".
>
>
>But, my point was, when you are defining an API, you cannot quantify
>the 'past' to be just the very 'close past' or 'the past is just the
>management routes that were added' . Tomorrow the 'past' can be the
>full routing table if you need to reset the hardware state.
Sure.
^ permalink raw reply
* Re: [PATCH net-next v2] ipv4: fib: Replay events when registering FIB notifier
From: Ido Schimmel @ 2016-11-02 13:44 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Jiri Pirko, Eric Dumazet, netdev@vger.kernel.org,
davem@davemloft.net, Jiri Pirko, mlxsw, David Ahern,
Nikolay Aleksandrov, Andy Gospodarek, Vivien Didelot, Andrew Lunn,
Florian Fainelli, alexander.h.duyck, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Ido Schimmel
In-Reply-To: <CAJieiUjGHX0C7mG3Y8m2VZHPPq=Rz-2D8e_L9ZASi-bCs8nJJw@mail.gmail.com>
On Wed, Nov 02, 2016 at 06:29:40AM -0700, Roopa Prabhu wrote:
> On Wed, Nov 2, 2016 at 12:20 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> > Wed, Nov 02, 2016 at 03:13:42AM CET, roopa@cumulusnetworks.com wrote:
> >>
> [snip]
>
> >>I understand..but, if you are adding some core infrastructure for switchdev ..it cannot be
> >>based on the number of simple use-cases or data you have today.
> >>
> >>I won't be surprised if tomorrow other switch drivers have a case where they need to
> >>reset the hw routing table state and reprogram all routes again. Re-registering the notifier to just
> >>get the routing state of the kernel will not scale. For the long term, since the driver does not maintain a cache,
> >
> > Driver (mlxsw, rocker) maintain a cache. So I'm not sure why you say
> > otherwise.
> >
> >
> >>a pull api with efficient use of rtnl will be useful for other such cases as well.
> >
> > How do you imagine this "pull API" should look like?
>
>
> Just like you already have added fib notifiers to parallel fib netlink
> notifications, the pull API is a parallel to 'netlink dump'.
> Is my imagination too wild ? :)
The question is more about the mechanics of this pull API, because it's
not very clear to me how that should look like. You want consumers to
dump the tables in batches, so that rtnl is held only during the batch
but not in between them? How are the routes passed down? Does the fib
code fill up some struct or does it use the fib chain?
> >>If you don't want to get to the complexity of a new api right away because of the
> >>simple case of management interface routes you have, Can your driver register the notifier early ?
> >>(I am sure you have probably already thought about this)
> >
> > Register early? What it would resolve? I must be missing something. We
> > register as early as possible. But the thing is, we cannot register
> > in a past. And that is what this patch resolves.
>
> sure, you must be having a valid problem then. I was just curious why
> your driver is not up and initialized before any of the addresses or
> routes get configured in the system (even on a management port). Ours
> does. But i agree there can be races and you cannot always guarantee
> (I was just responding to ido's comment about adding complexity for a
> small problem he has to solve for management routes). Our driver does
> a pull before it starts. This helps when we want to reset the hardware
> routing table state too.
One can modprobe the module after routes are already present on other
netdevs. That's actually how I tested the patch.
^ permalink raw reply
* Re: [PATCH net-next v2 3/5] bpf: BPF for lightweight tunnel encapsulation
From: Roopa Prabhu @ 2016-11-02 13:39 UTC (permalink / raw)
To: Thomas Graf; +Cc: davem, alexei.starovoitov, daniel, tom, netdev
In-Reply-To: <d8c7e07ac7d289a2846af8d659287f3512a4edec.1477959702.git.tgraf@suug.ch>
On 10/31/16, 5:37 PM, Thomas Graf wrote:
> Register two new BPF prog types BPF_PROG_TYPE_LWT_IN and
> BPF_PROG_TYPE_LWT_OUT which are invoked if a route contains a
> LWT redirection of type LWTUNNEL_ENCAP_BPF.
>
> The separate program types are required because manipulation of
> packet data is only allowed on the output and transmit path as
> the subsequent dst_input() call path assumes an IP header
> validated by ip_rcv(). The BPF programs will be handed an skb
> with the L3 header attached and may return one of the following
> return codes:
>
> BPF_OK - Continue routing as per nexthop
> BPF_DROP - Drop skb and return EPERM
> BPF_REDIRECT - Redirect skb to device as per redirect() helper.
> (Only valid on lwtunnel_xmit() hook)
>
> The return codes are binary compatible with their TC_ACT_
> relatives to ease compatibility.
>
> A new helper bpf_skb_push() is added which allows to preprend an
> L2 header in front of the skb, extend the existing L3 header, or
> both. This allows to address a wide range of issues:
> - Optimize L2 header construction when L2 information is always
> static to avoid ARP/NDisc lookup.
> - Extend IP header to add additional IP options.
> - Perform simple encapsulation where offload is of no concern.
> (The existing funtionality to attach a tunnel key to the skb
> and redirect to a tunnel net_device to allow for offload
> continues to work obviously).
>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
> ---
>
[snip]
> diff --git a/net/Kconfig b/net/Kconfig
> index 7b6cd34..7554f12 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -396,6 +396,7 @@ source "net/nfc/Kconfig"
>
> config LWTUNNEL
> bool "Network light weight tunnels"
> + depends on IPV6 || IPV6=n
> ---help---
> This feature provides an infrastructure to support light weight
> tunnels like mpls. There is no netdevice associated with a light
> diff --git a/net/core/Makefile b/net/core/Makefile
> index d6508c2..a675fd3 100644
> --- a/net/core/Makefile
> +++ b/net/core/Makefile
> @@ -23,7 +23,7 @@ obj-$(CONFIG_NETWORK_PHY_TIMESTAMPING) += timestamping.o
> obj-$(CONFIG_NET_PTP_CLASSIFY) += ptp_classifier.o
> obj-$(CONFIG_CGROUP_NET_PRIO) += netprio_cgroup.o
> obj-$(CONFIG_CGROUP_NET_CLASSID) += netclassid_cgroup.o
> -obj-$(CONFIG_LWTUNNEL) += lwtunnel.o
> +obj-$(CONFIG_LWTUNNEL) += lwtunnel.o lwt_bpf.o
Any reason you want to keep lwt bpf under the main CONFIG_LWTUNNEL infra config ?.
since it is defined as yet another plug-gable encap function, seems like it will be better under a separate
CONFIG_LWTUNNEL_BPF or CONFIG_LWT_BPF that depends on CONFIG_LWTUNNEL
^ 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