On 4/22/24 7:48 AM, Jakub Kicinski wrote:
> On Sun, 21 Apr 2024 13:32:24 -0600 David Ahern wrote:
>> On 4/21/24 1:17 PM, Eric Dumazet wrote:
>>> I wonder if NLM_F_DUMP_FILTERED should not be reported to user space ?
>>
>> good point. We do set that flag for othe
On 4/21/24 1:17 PM, Eric Dumazet wrote:
> I wonder if NLM_F_DUMP_FILTERED should not be reported to user space ?
good point. We do set that flag for other dumps when a filter has been
used to limit data returned.
t fits remains unaddressed.
>
> Signed-off-by: Jakub Kicinski
> ---
> net/netlink/af_netlink.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
Reviewed-by: David Ahern
On 4/19/24 8:35 PM, Jakub Kicinski wrote:
> Next change will need them in netlink_dump_done(), pure move.
>
> Signed-off-by: Jakub Kicinski
> ---
> net/netlink/af_netlink.c | 126 +++
> 1 file changed, 63 insertions(+), 63 deletions(-)
>
ore/netdev-genl-gen.c | 1 +
> net/core/netdev-genl.c | 52 ++---
> 3 files changed, 41 insertions(+), 13 deletions(-)
>
Reviewed-by: David Ahern
On 4/12/24 11:03 AM, Petr Machata wrote:
> This test lacks a topology diagram, making the setup not obvious.
> Add one.
>
> Cc: David Ahern
> Signed-off-by: Petr Machata
> ---
> .../net/forwarding/router_mpath_nh.sh | 35 +++
> 1 fil
On 3/17/24 8:38 PM, Hangbin Liu wrote:
> Wild guess, the last change of icmp_redirect is my netns update. Maybe
> there are something default sysctl settings in netns cause the error?
It is most likely sysctl settings. It would be good to chase those down
and make sure we have the script setting
On 3/11/24 10:17 AM, Jakub Kicinski wrote:
> On Sat, 9 Mar 2024 19:45:15 +0100 Mirsad Todorovac wrote:
>> In the vanilla net-next tree build of v6.8-rc7-2348-g75c2946db360, with
>> up-to-date
>> iproute2 built tools, fcnal-test.sh reports certain failures:
>>
>>
On 3/8/24 4:47 PM, David Wei wrote:
>
> I'm working to port bnxt over to using this API. What are your thoughts
> on maybe pulling this out and use bnxt to drive it?
>
I would love to see a second nic implementation; this patch set and
overall design is driven by GVE limitations.
On 3/8/24 4:47 PM, David Wei wrote:
>
> I'm working to port bnxt over to using this API. What are your thoughts
> on maybe pulling this out and use bnxt to drive it?
>
I would love to see a second nic implementation; this patch set and
overall design is driven by GVE limitations.
+-
> tools/testing/selftests/net/rtnetlink.sh | 6 ++---
> tools/testing/selftests/net/udpgro_fwd.sh | 14 +--
> tools/testing/selftests/net/udpgso_bench_rx.c | 2 +-
> 4 files changed, 32 insertions(+), 13 deletions(-)
>
For the set:
Reviewed-by: David Ahern
lftests: net: fix available tunnels detection
> selftests: net: don't access /dev/stdout in pmtu.sh
>
> tools/testing/selftests/net/config | 3 +++
> tools/testing/selftests/net/pmtu.sh | 18 +-
> 2 files changed, 12 insertions(+), 9 deletions(-)
>
selftests are getting a lot of love right now :-)
Reviewed-by: David Ahern
On 1/5/24 2:41 AM, Mirsad Todorovac wrote:
> diff --git a/tools/testing/selftests/net/settings
> b/tools/testing/selftests/net/settings index dfc27cdc6c05..ed8418e8217a
> 100644 --- a/tools/testing/selftests/net/settings +++
> b/tools/testing/selftests/net/settings @@ -1 +1 @@ -timeout=1500
>
+-
> 2 files changed, 42 insertions(+), 10 deletions(-)
>
Reviewed-by: David Ahern
an incoming packet.
>
> Signed-off-by: Richard Gobert
> Reviewed-by: Willem de Bruijn
> ---
> net/ipv6/exthdrs_offload.c | 11 +++
> net/ipv6/ip6_offload.c | 25 +++--
> 2 files changed, 22 insertions(+), 14 deletions(-)
>
Reviewed-by: David Ahern
On 12/12/23 6:09 PM, Mina Almasry wrote:
> OK, I imagine this is not that hard to implement - it's really whether
> the change is acceptable to reviewers.
>
> I figure I can start by implementing a no-op abstraction to page*:
>
> typedef struct page netmem_t
>
> and replace the page* in the
On 12/12/23 6:09 PM, Mina Almasry wrote:
> OK, I imagine this is not that hard to implement - it's really whether
> the change is acceptable to reviewers.
>
> I figure I can start by implementing a no-op abstraction to page*:
>
> typedef struct page netmem_t
>
> and replace the page* in the
On 12/8/23 12:22 PM, Mina Almasry wrote:
> On Fri, Dec 8, 2023 at 9:48 AM David Ahern wrote:
>>
>> On 12/7/23 5:52 PM, Mina Almasry wrote:
> ...
>>> +
>>> + xa_for_each(>bound_rxq_list, xa_idx, rxq) {
>>> + if (rxq->binding
On 12/8/23 12:22 PM, Mina Almasry wrote:
> On Fri, Dec 8, 2023 at 9:48 AM David Ahern wrote:
>>
>> On 12/7/23 5:52 PM, Mina Almasry wrote:
> ...
>>> +
>>> + xa_for_each(>bound_rxq_list, xa_idx, rxq) {
>>> + if (rxq->binding
On 12/7/23 5:52 PM, Mina Almasry wrote:
> Major changes in v1:
> --
>
> 1. Implemented MVP queue API ndos to remove the userspace-visible
>driver reset.
>
> 2. Fixed issues in the napi_pp_put_page() devmem frag unref path.
>
> 3. Removed RFC tag.
>
> Many smaller addressed
On 12/7/23 5:52 PM, Mina Almasry wrote:
> Major changes in v1:
> --
>
> 1. Implemented MVP queue API ndos to remove the userspace-visible
>driver reset.
>
> 2. Fixed issues in the napi_pp_put_page() devmem frag unref path.
>
> 3. Removed RFC tag.
>
> Many smaller addressed
On 12/7/23 5:52 PM, Mina Almasry wrote:
> diff --git a/net/core/dev.c b/net/core/dev.c
> index b8c8be5a912e..30667e4c3b95 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2120,6 +2120,41 @@ static int netdev_restart_rx_queue(struct net_device
> *dev, int rxq_idx)
> return err;
>
On 12/7/23 5:52 PM, Mina Almasry wrote:
> diff --git a/net/core/dev.c b/net/core/dev.c
> index b8c8be5a912e..30667e4c3b95 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2120,6 +2120,41 @@ static int netdev_restart_rx_queue(struct net_device
> *dev, int rxq_idx)
> return err;
>
On 12/7/23 5:52 PM, Mina Almasry wrote:
> In tcp_recvmsg_locked(), detect if the skb being received by the user
> is a devmem skb. In this case - if the user provided the MSG_SOCK_DEVMEM
> flag - pass it to tcp_recvmsg_devmem() for custom handling.
>
> tcp_recvmsg_devmem() copies any data in the
On 12/7/23 5:52 PM, Mina Almasry wrote:
> In tcp_recvmsg_locked(), detect if the skb being received by the user
> is a devmem skb. In this case - if the user provided the MSG_SOCK_DEVMEM
> flag - pass it to tcp_recvmsg_devmem() for custom handling.
>
> tcp_recvmsg_devmem() copies any data in the
On 12/7/23 5:52 PM, Mina Almasry wrote:
> +
> +static int netdev_restart_rx_queue(struct net_device *dev, int rxq_idx)
> +{
> + void *new_mem;
> + void *old_mem;
> + int err;
> +
> + if (!dev || !dev->netdev_ops)
> + return -EINVAL;
> +
> + if
On 12/7/23 5:52 PM, Mina Almasry wrote:
> +
> +static int netdev_restart_rx_queue(struct net_device *dev, int rxq_idx)
> +{
> + void *new_mem;
> + void *old_mem;
> + int err;
> +
> + if (!dev || !dev->netdev_ops)
> + return -EINVAL;
> +
> + if
On 12/7/23 3:34 AM, Petr Machata wrote:
> But what I object against is that the library uses trap without having a
> way for user scripts to schedule at-exit work, because that's used
> literally everywhere in forwarding tests.
+1
350s
> sys 22m17.432s
>
>
I have not looked at the details of each script change, but as long as
not test is broken by the change I am fine with the intent.
Acked-by: David Ahern
On 11/10/23 7:26 AM, Pavel Begunkov wrote:
> On 11/7/23 23:03, Mina Almasry wrote:
>> On Tue, Nov 7, 2023 at 2:55 PM David Ahern wrote:
>>>
>>> On 11/7/23 3:10 PM, Mina Almasry wrote:
>>>> On Mon, Nov 6, 2023 at 3:44 PM David Ahern wrote:
>>>
On 11/10/23 7:26 AM, Pavel Begunkov wrote:
> On 11/7/23 23:03, Mina Almasry wrote:
>> On Tue, Nov 7, 2023 at 2:55 PM David Ahern wrote:
>>>
>>> On 11/7/23 3:10 PM, Mina Almasry wrote:
>>>> On Mon, Nov 6, 2023 at 3:44 PM David Ahern wrote:
>>>
On 11/7/23 5:02 PM, Mina Almasry wrote:
> On Mon, Nov 6, 2023 at 1:02 PM Stanislav Fomichev wrote:
>>
>> On 11/05, Mina Almasry wrote:
>>> +static inline bool page_is_page_pool_iov(const struct page *page)
>>> +{
>>> + return (unsigned long)page & PP_DEVMEM;
>>> +}
>>
>> Speaking of bpf: one
On 11/7/23 5:02 PM, Mina Almasry wrote:
> On Mon, Nov 6, 2023 at 1:02 PM Stanislav Fomichev wrote:
>>
>> On 11/05, Mina Almasry wrote:
>>> +static inline bool page_is_page_pool_iov(const struct page *page)
>>> +{
>>> + return (unsigned long)page & PP_DEVMEM;
>>> +}
>>
>> Speaking of bpf: one
On 11/7/23 4:55 PM, Mina Almasry wrote:
> On Mon, Nov 6, 2023 at 4:03 PM Willem de Bruijn
> wrote:
>>
>> On Mon, Nov 6, 2023 at 3:55 PM David Ahern wrote:
>>>
>>> On 11/6/23 4:32 PM, Stanislav Fomichev wrote:
>>>>> The concise notification
On 11/7/23 4:55 PM, Mina Almasry wrote:
> On Mon, Nov 6, 2023 at 4:03 PM Willem de Bruijn
> wrote:
>>
>> On Mon, Nov 6, 2023 at 3:55 PM David Ahern wrote:
>>>
>>> On 11/6/23 4:32 PM, Stanislav Fomichev wrote:
>>>>> The concise notification
On 11/7/23 3:10 PM, Mina Almasry wrote:
> On Mon, Nov 6, 2023 at 3:44 PM David Ahern wrote:
>>
>> On 11/5/23 7:44 PM, Mina Almasry wrote:
>>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>>> index eeeda849115c..1c351c138a5b 100644
&g
On 11/7/23 3:10 PM, Mina Almasry wrote:
> On Mon, Nov 6, 2023 at 3:44 PM David Ahern wrote:
>>
>> On 11/5/23 7:44 PM, Mina Almasry wrote:
>>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>>> index eeeda849115c..1c351c138a5b 100644
&g
Is there a policy about cc'ing moderated lists on patch sets? I thought
there was, but not finding anything under Documentation/. Getting a
'needs moderator approval response' on every message is rather annoying.
Is there a policy about cc'ing moderated lists on patch sets? I thought
there was, but not finding anything under Documentation/. Getting a
'needs moderator approval response' on every message is rather annoying.
On 11/6/23 5:20 PM, Mina Almasry wrote:
> The user is free to modify or delete flow steering rules outside of the
> lifetime of the socket. Technically it's possible for the user to
> reconfigure flow steering while the socket is simultaneously receiving,
> and the result will be packets switching
On 11/6/23 5:20 PM, Mina Almasry wrote:
> The user is free to modify or delete flow steering rules outside of the
> lifetime of the socket. Technically it's possible for the user to
> reconfigure flow steering while the socket is simultaneously receiving,
> and the result will be packets switching
On 11/5/23 7:44 PM, Mina Almasry wrote:
> diff --git a/net/core/datagram.c b/net/core/datagram.c
> index 176eb5834746..cdd4fb129968 100644
> --- a/net/core/datagram.c
> +++ b/net/core/datagram.c
> @@ -425,6 +425,9 @@ static int __skb_datagram_iter(const struct sk_buff *skb,
> int offset,
>
On 11/5/23 7:44 PM, Mina Almasry wrote:
> diff --git a/net/core/datagram.c b/net/core/datagram.c
> index 176eb5834746..cdd4fb129968 100644
> --- a/net/core/datagram.c
> +++ b/net/core/datagram.c
> @@ -425,6 +425,9 @@ static int __skb_datagram_iter(const struct sk_buff *skb,
> int offset,
>
On 11/6/23 4:32 PM, Stanislav Fomichev wrote:
>> The concise notification API returns tokens as a range for
>> compression, encoding as two 32-bit unsigned integers start + length.
>> It allows for even further batching by returning multiple such ranges
>> in a single call.
>
> Tangential: should
On 11/6/23 4:32 PM, Stanislav Fomichev wrote:
>> The concise notification API returns tokens as a range for
>> compression, encoding as two 32-bit unsigned integers start + length.
>> It allows for even further batching by returning multiple such ranges
>> in a single call.
>
> Tangential: should
On 11/5/23 7:44 PM, Mina Almasry wrote:
> diff --git a/include/net/page_pool/helpers.h b/include/net/page_pool/helpers.h
> index 78cbb040af94..b93243c2a640 100644
> --- a/include/net/page_pool/helpers.h
> +++ b/include/net/page_pool/helpers.h
> @@ -111,6 +112,45 @@ page_pool_iov_binding(const
On 11/5/23 7:44 PM, Mina Almasry wrote:
> diff --git a/include/net/page_pool/helpers.h b/include/net/page_pool/helpers.h
> index 78cbb040af94..b93243c2a640 100644
> --- a/include/net/page_pool/helpers.h
> +++ b/include/net/page_pool/helpers.h
> @@ -111,6 +112,45 @@ page_pool_iov_binding(const
On 11/5/23 7:44 PM, Mina Almasry wrote:
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index eeeda849115c..1c351c138a5b 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -843,6 +843,9 @@ struct netdev_dmabuf_binding {
> };
>
> #ifdef
On 11/5/23 7:44 PM, Mina Almasry wrote:
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index eeeda849115c..1c351c138a5b 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -843,6 +843,9 @@ struct netdev_dmabuf_binding {
> };
>
> #ifdef
On 11/6/23 3:18 PM, Mina Almasry wrote:
>> @@ -991,7 +993,7 @@ struct sk_buff {
>> #if IS_ENABLED(CONFIG_IP_SCTP)
>> __u8csum_not_inet:1;
>> #endif
>> -
>> +__u8devmem:1;
>> #if defined(CONFIG_NET_SCHED) ||
On 11/6/23 3:18 PM, Mina Almasry wrote:
>> @@ -991,7 +993,7 @@ struct sk_buff {
>> #if IS_ENABLED(CONFIG_IP_SCTP)
>> __u8csum_not_inet:1;
>> #endif
>> -
>> +__u8devmem:1;
>> #if defined(CONFIG_NET_SCHED) ||
On 11/6/23 11:47 AM, Stanislav Fomichev wrote:
> On 11/05, Mina Almasry wrote:
>> For device memory TCP, we expect the skb headers to be available in host
>> memory for access, and we expect the skb frags to be in device memory
>> and unaccessible to the host. We expect there to be no mixing and
On 11/6/23 11:47 AM, Stanislav Fomichev wrote:
> On 11/05, Mina Almasry wrote:
>> For device memory TCP, we expect the skb headers to be available in host
>> memory for access, and we expect the skb frags to be in device memory
>> and unaccessible to the host. We expect there to be no mixing and
On 10/23/23 1:12 AM, Jiri Pirko wrote:
>> ip addr add ...
>
> Why not "address" then? :)
no objection from me.
> What's wrong with "a"?
1-letter commands can be ambiguous. Test scripts should be clear and
obvious.
ifconfig veth0 127.25.3.4/24 up
> -ip netns exec "${PEER_NS}" ifconfig veth1 127.25.3.14/24 up
> +ip address add 127.25.3.4/24 dev veth0
> +ip link set dev veth0 up
> +ip netns exec "${PEER_NS}" ip address add 127.25.3.14/24 dev veth1
> +ip netns exec "${PEER_NS}" ip link set dev veth1 up
>
> ip route flush cache
> ip netns exec "${PEER_NS}" ip route flush cache
Reviewed-by: David Ahern
On 10/22/23 5:31 AM, Swarup Laxman Kotiaklapudi wrote:
> diff --git a/tools/testing/selftests/net/route_localnet.sh
> b/tools/testing/selftests/net/route_localnet.sh
> index 116bfeab72fa..3ab9beb4462c 100755
> --- a/tools/testing/selftests/net/route_localnet.sh
> +++
check
> for CONFIG_IPV6.
>
> Fixes: fc651001d2c5ca4f ("neighbor: Add tracepoint to __neigh_create")
> Signed-off-by: Geert Uytterhoeven
> ---
> No changes in generated code.
>
> include/trace/events/neigh.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: David Ahern
Google put your email in the spam folder, BTW.
n time
> memory bloat by ~64 bytes per sentinel (further information Link :
> https://lore.kernel.org/all/zo5yx5jfoggi%2f...@bombadil.infradead.org/)
>
> Remove sentinel from vrf_table
>
> Signed-off-by: Joel Granados
> ---
> drivers/net/vrf.c | 1 -
> 1 file changed, 1 deletion(-)
>
Reviewed-by: David Ahern
ray indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
> functions).
>
> As found with Coccinelle[1], add __counted_by for struct nh_group.
>
> Cc: David Ahern
> Cc: "David S. Miller"
> Cc: Eric Dumazet
> Cc: Jakub Kicinski
> Cc: Paolo Abeni
> Cc: net...@vger.
ray indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
> functions).
>
> As found with Coccinelle[1], add __counted_by for struct nh_notifier_grp_info.
>
> Cc: David Ahern
> Cc: "David S. Miller"
> Cc: Eric Dumazet
> Cc: Jakub Kicinski
> Cc: Paolo Abeni
> Cc: Nath
ray indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
> functions).
>
> As found with Coccinelle[1], add __counted_by for struct
> nh_notifier_res_table_info.
>
> Cc: David Ahern
> Cc: "David S. Miller"
> Cc: Eric Dumazet
> Cc: Jakub Kicinski
> Cc: Paolo Abeni
&
ray indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
> functions).
>
> As found with Coccinelle[1], add __counted_by for struct nh_res_table.
>
> Cc: David Ahern
> Cc: "David S. Miller"
> Cc: Eric Dumazet
> Cc: Jakub Kicinski
> Cc: Paolo Abeni
> Cc: net...@vger.
n time
> memory bloat by ~64 bytes per sentinel (further information Link :
> https://lore.kernel.org/all/zo5yx5jfoggi%2f...@bombadil.infradead.org/)
>
> Remove sentinel from vrf_table
>
> Signed-off-by: Joel Granados
> ---
> drivers/net/vrf.c | 1 -
> 1 file changed, 1 deletion(-)
>
Reviewed-by: David Ahern
n time
> memory bloat by ~64 bytes per sentinel (further information Link :
> https://lore.kernel.org/all/zo5yx5jfoggi%2f...@bombadil.infradead.org/)
>
> Remove sentinel from vrf_table
>
> Signed-off-by: Joel Granados
> ---
> drivers/net/vrf.c | 1 -
> 1 file changed,
n time
> memory bloat by ~64 bytes per sentinel (further information Link :
> https://lore.kernel.org/all/zo5yx5jfoggi%2f...@bombadil.infradead.org/)
>
> Remove sentinel from vrf_table
>
> Signed-off-by: Joel Granados
> ---
> drivers/net/vrf.c | 1 -
> 1 file changed, 1 deletion(-)
>
Reviewed-by: David Ahern
n time
> memory bloat by ~64 bytes per sentinel (further information Link :
> https://lore.kernel.org/all/zo5yx5jfoggi%2f...@bombadil.infradead.org/)
>
> Remove sentinel from vrf_table
>
> Signed-off-by: Joel Granados
> ---
> drivers/net/vrf.c | 1 -
> 1 file changed, 1 deletion(-)
>
Reviewed-by: David Ahern
On 9/15/23 9:59 AM, Stephen Hemminger wrote:
> On Wed, 13 Sep 2023 19:58:25 +0200
> Andrea Claudi wrote:
>
>> This commit allows users/packagers to choose a default for the color
>> output feature provided by some iproute2 tools.
>>
>> The configure script option is documented in the script
On 8/23/23 3:52 PM, David Wei wrote:
> I'm also preparing a submission for NetDev conf. I wonder if you and others at
> Google plan to present there as well? If so, then we may want to coordinate
> our
> submissions and talks (if accepted).
personally, I see them as related but separate topics.
On 8/19/23 9:22 AM, Jesper Dangaard Brouer wrote:
>
> I do see the problem of depending on having a struct page, as the
> page_pool_iov isn't related to struct page. Having "page" in the name
> of "page_pool_iov" is also confusing (hardest problem is CS is naming,
> as we all know).
>
> To
On 8/9/23 7:57 PM, Mina Almasry wrote:
> Changes in RFC v2:
> --
>
> The sticking point in RFC v1[1] was the dma-buf pages approach we used to
> deliver the device memory to the TCP stack. RFC v2 is a proof-of-concept
> that attempts to resolve this by implementing scatterlist
On 8/9/23 7:57 PM, Mina Almasry wrote:
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 8e7d0cb540cd..02a25ccf771a 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -151,6 +151,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "dev.h"
> #include
On 7/18/23 12:29 PM, Jakub Kicinski wrote:
> On Tue, 18 Jul 2023 12:20:59 -0600 David Ahern wrote:
>> On 7/18/23 12:15 PM, Jakub Kicinski wrote:
>>> On Tue, 18 Jul 2023 15:06:29 -0300 Jason Gunthorpe wrote:
>>>> netlink feels like a weird API choice fo
On 7/18/23 12:15 PM, Jakub Kicinski wrote:
> On Tue, 18 Jul 2023 15:06:29 -0300 Jason Gunthorpe wrote:
>> netlink feels like a weird API choice for that, in particular it would
>> be really wrong to somehow bind the lifecycle of a netlink object to a
>> process.
>
> Netlink is the right API, life
| 1 +
> net/bridge/br_netlink.c | 12 +
> net/bridge/br_private.h | 3 +
> net/bridge/br_vlan_tunnel.c | 15 +
> net/core/rtnetlink.c | 2 +-
> tools/testing/selftests/net/Makefile | 1 +
> .../selftests/net/test_bridge_backup_port.sh | 759 ++
> 10 files changed, 838 insertions(+), 1 deletion(-)
> create mode 100755 tools/testing/selftests/net/test_bridge_backup_port.sh
>
For the series:
Acked-by: David Ahern
On 7/13/23 1:09 AM, Ido Schimmel wrote:
> tl;dr
> =
>
> This patchset adds a new bridge port attribute specifying the nexthop
> object ID to attach to a redirected skb as tunnel metadata. The ID is
> used by the VXLAN driver to choose the target VTEP for the skb. This is
> useful for EVPN
On 4/3/23 9:24 AM, Stephen Hemminger wrote:
> ted
>>
>> This happens because iproute2 just assumes the tunnel is ipv4, but the
>> kernel "knows" it's actually ip6gre so when calling the SIOCGETTUNNEL
>> ioctl it writes back a struct ip6_tnl_parm2 into the struct
>> ip_tunnel_parm which is smaller,
On 4/3/23 9:24 AM, Stephen Hemminger wrote:
> ted
>>
>> This happens because iproute2 just assumes the tunnel is ipv4, but the
>> kernel "knows" it's actually ip6gre so when calling the SIOCGETTUNNEL
>> ioctl it writes back a struct ip6_tnl_parm2 into the struct
>> ip_tunnel_parm which is smaller,
David Ahern created SPARK-40317:
---
Summary: Improvement to JDBC predicate for queries involving joins
Key: SPARK-40317
URL: https://issues.apache.org/jira/browse/SPARK-40317
Project: Spark
documentation link on Sourceforge says it is abandoned there.
>
> Leave the UAPI alone to keep userspace programs compiling.
>
> Signed-off-by: Stephen Hemminger
> ---
Acked-by: David Ahern
On 6/8/22 8:58 AM, Jakub Kicinski wrote:
> IMO to encourage use of the track-capable API we could keep their names
> short and call the legacy functions __netdev_hold() as I mentioned or
> maybe netdev_hold_notrack().
I like that option. Similar to the old nla_parse functions that were
renamed
On Mon, Apr 11, 2022 at 12:22:24PM -0700, Roopa Prabhu wrote:
> all great points. My only reason to explore RTM_DELNEIGH is to see if we can
> find a recipe to support similar bulk deletes of other objects handled via
> rtm msgs in the future. Plus, it allows you to maintain symmetry between
>
On 4/13/22 6:21 AM, Nikolay Aleksandrov wrote:
>> If a buggy user space application is sending messages with NLM_F_BULK
>> set (unintentionally), will it break on newer kernel? I couldn't find
>> where the kernel was validating that reserved flags are not used (I
>> suspect it doesn't).
>
>
On 4/12/22 7:22 AM, Nikolay Aleksandrov wrote:
> Hi,
> This patch-set adds support to specify filtering conditions for a bulk
> delete (flush) operation. This version uses a new nlmsghdr delete flag
> called NLM_F_BULK in combination with a new ndo_fdb_del_bulk op which is
> used to signal that
On Mon, Apr 11, 2022 at 08:29:27PM +0300, Nikolay Aleksandrov wrote:
> Add a new rtnetlink type used to flush neigh objects. It will be
> initially used to add flush with filtering support for bridge fdbs, but
> it also opens the door to add similar support to others (e.g. vxlan).
>
>
On 12/20/21 12:11 PM, Parav Pandit wrote:
>> After consideration, this future proofing seems like a good thing to have.
> Ok. I will first get kernel change merged, after which will send v3 for
> iproute2.
this set has been committed; not sure what happened to the notification
from patchworks
On 12/17/21 1:08 AM, Parav Pandit wrote:
> @@ -204,6 +217,8 @@ static void vdpa_opts_put(struct nlmsghdr *nlh, struct
> vdpa *vdpa)
> if (opts->present & VDPA_OPT_VDEV_MAC)
> mnl_attr_put(nlh, VDPA_ATTR_DEV_NET_CFG_MACADDR,
>sizeof(opts->mac),
On 12/1/21 9:22 PM, Parav Pandit wrote:
> @@ -233,6 +254,15 @@ static int vdpa_argv_parse(struct vdpa *vdpa, int argc,
> char **argv,
>
> NEXT_ARG_FWD();
> o_found |= VDPA_OPT_VDEV_MGMTDEV_HANDLE;
> + } else if ((matches(*argv, "mac") ==
On 12/1/21 9:22 PM, Parav Pandit wrote:
> @@ -154,6 +156,31 @@ static int vdpa_argv_mac(struct vdpa *vdpa, int argc,
> char **argv, char *mac)
> return 0;
> }
>
> +static int strtouint16_t(const char *str, uint16_t *p_val)
> +{
> + char *endptr;
> + unsigned long int val;
> +
> +
On 12/1/21 9:22 PM, Parav Pandit wrote:
> This series implements querying and setting of the mac address and mtu
> device config fields of the vdpa device of type net.
>
> An example of query and set as below.
>
> $ vdpa dev add name bar mgmtdev vdpasim_net mac 00:11:22:33:44:55 mtu 9000
>
> $
On 11/30/21 10:07 AM, Jakub Kicinski wrote:
> On Tue, 30 Nov 2021 17:17:24 +0100 Toke Høiland-Jørgensen wrote:
>>> 1. Channels vs queues vs global.
>>>
>>> Jakub: no per-channel.
>>> David (Ahern): it's worth it to separate as Rx/Tx.
>>> Toke is fi
On 11/30/21 8:56 AM, Alexander Lobakin wrote:
> Rest:
> - don't create a separate `ip` command and report under `-s`;
Reporting XDP stats under 'ip -s' is not going to be scalable from a
readability perspective.
ifstat (misc/ifstat.c) has support for extended stats which is where you
are adding
On 11/30/21 10:04 AM, Jakub Kicinski wrote:
> On Tue, 30 Nov 2021 17:34:54 +0100 Alexander Lobakin wrote:
>>> Another thought on this patch: with individual attributes you could save
>>> some overhead by not sending 0 counters to userspace. e.g., define a
>>> helper that does:
>>
>> I know about
On 11/23/21 9:39 AM, Alexander Lobakin wrote:
> +static bool rtnl_get_xdp_stats_xdpxsk(struct sk_buff *skb, u32 ch,
> + const void *attr_data)
> +{
> + const struct ifla_xdp_stats *xstats = attr_data;
> +
> + xstats += ch;
> +
> + if
On 11/23/21 9:39 AM, Alexander Lobakin wrote:
> This is an almost complete rework of [0].
>
> This series introduces generic XDP statistics infra based on rtnl
> xstats (Ethtool standard stats previously), and wires up the drivers
> which collect appropriate statistics to this new interface.
On 9/20/21 9:34 AM, Antoine Tenart wrote:
> There might be questions about the setup in which a VRF is linked to an
> OVS bridge; I cc'ed Luis Tomás who wrote the article.
My head just exploded. You want to make an L3 device a port of an L2
device.
Can someone explain how this is supposed to
On 8/4/21 12:27 PM, Saeed Mahameed wrote:
>
>> I just ran some quick tests with my setup and measured about 1.2%
>> worst
>
> 1.2% is a lot ! what was the test ? what is the change ?
I did say "quick test ... not exhaustive" and it was definitely
eyeballing a pps change over a small time
On 8/4/21 10:44 AM, Jakub Kicinski wrote:
> On Wed, 4 Aug 2021 10:17:56 -0600 David Ahern wrote:
>> On 8/4/21 6:36 AM, Jakub Kicinski wrote:
>>>> XDP is going to always be eBPF based ! why not just report such stats
>>>> to a special BPF_MAP ? BPF stack can
On 8/4/21 6:36 AM, Jakub Kicinski wrote:
>> XDP is going to always be eBPF based ! why not just report such stats
>> to a special BPF_MAP ? BPF stack can collect the stats from the driver
>> and report them to this special MAP upon user request.
> Do you mean replacing the ethtool-netlink /
On 5/5/21 9:27 PM, Hoang Le wrote:
> When receiving a result from first query to netlink, we may exec
> a another query inside the callback. If calling this sub-routine
> in the same socket, it will be discarded the result from previous
> exection.
> To avoid this we perform a nested query in
On 4/16/21 2:16 AM, Xuan Zhuo wrote:
> In page_to_skb(), if we have enough tailroom to save skb_shared_info, we
> can use build_skb to create skb directly. No need to alloc for
> additional space. And it can save a 'frags slot', which is very friendly
> to GRO.
>
> Here, if the payload of the
1 - 100 of 7749 matches
Mail list logo
