Hi David,
On Thu, Jul 09, 2020 at 10:33:38AM -0600, David Ahern wrote:
> > +bool dev_in_exclude_map(struct bpf_dtab_netdev *obj, struct bpf_map *map,
> > + int exclude_ifindex)
> > +{
> > + struct bpf_dtab_netdev *ex_obj = NULL;
> > + u32 key, next_key;
> > + int err;
> > +
In the skb Tx path, transmission of a packet is performed with
dev_direct_xmit(). When QUEUE_STATE_FROZEN is set in the transmit
routines, it returns NETDEV_TX_BUSY signifying that it was not
possible to send the packet now, please try later. Unfortunately, the
xsk transmit code discarded the packe
On 2020/7/10 下午1:39, Eugenio Perez Martin wrote:
It is allocated 1 thread in lcore 1 (F_THREAD=1) which belongs to the
same NUMA as testpmd. Actually, it is the testpmd master core, so it
should be a good idea to move it to another lcore of the same NUMA
node.
Is this enough for pktgen to allo
On Fri, Jul 10, 2020 at 12:40:11AM +0200, Daniel Borkmann wrote:
> > +SEC("xdp_redirect_map_multi")
> > +int xdp_redirect_map_multi_prog(struct xdp_md *ctx)
> > +{
> > + long *value;
> > + u32 key = 0;
> > +
> > + /* count packet in global counter */
> > + value = bpf_map_lookup_elem(&rxcnt
On 7/8/20 8:15 PM, Andrii Nakryiko wrote:
On Thu, Jul 2, 2020 at 1:04 PM Alexei Starovoitov
wrote:
From: Alexei Starovoitov
Add kernel module with user mode driver that populates bpffs with
BPF iterators.
$ mount bpffs /sys/fs/bpf/ -t bpf
$ ls -la /sys/fs/bpf/
total 4
drwxrwxrwt 2 root
On Fri, Jul 10, 2020 at 5:56 AM Jakub Kicinski wrote:
>
> On Thu, 9 Jul 2020 14:26:52 -0700 Jacob Keller wrote:
> > The flash update for the ice hardware currently supports a single fixed
> > configuration:
> >
> > * Firmware is always asked to preserve all changeable fields
> > * The driver neve
On Thu, Jul 9, 2020 at 11:07 PM YU, Xiangning
wrote:
>
>
> On 7/9/20 10:20 PM, Cong Wang wrote:
> > On Thu, Jul 9, 2020 at 10:04 PM Cong Wang wrote:
> >> IOW, without these *additional* efforts, it is broken in terms of
> >> out-of-order.
> >>
> >
> > Take a look at fq_codel, it provides a hash f
Am 09.07.20 um 22:37 schrieb Daniel Borkmann:
On 7/9/20 9:42 PM, Alexander A. Klimov wrote:
Rationale:
Documentation/arm/ixp4xx.rst contains "xdp" as part of "ixdp465"
which has nothing to do with XDP.
Signed-off-by: Alexander A. Klimov
---
See also: https://lore.kernel.org/lkml/202007091
On Thu, Jul 9, 2020 at 10:49 PM YU, Xiangning
wrote:
>
> Well, we do ask packets from a flow to be classified to a single class, not
> multiple ones. It doesn't have to be socket priority, it could be five tuple
> hash, or even container classid.
I don't see how it is so in your code, without s
On 7/9/20 10:20 PM, Cong Wang wrote:
> On Thu, Jul 9, 2020 at 10:04 PM Cong Wang wrote:
>> IOW, without these *additional* efforts, it is broken in terms of
>> out-of-order.
>>
>
> Take a look at fq_codel, it provides a hash function for flow classification,
> fq_codel_hash(), as default, thus
On Fri, Jul 10, 2020 at 07:39:26AM +0200, Eugenio Perez Martin wrote:
> > > How about playing with the batch size? Make it a mod parameter instead
> > > of the hard coded 64, and measure for all values 1 to 64 ...
> >
> >
> > Right, according to the test result, 64 seems to be too aggressive in
> >
On 7/9/20 10:04 PM, Cong Wang wrote:
> On Wed, Jul 8, 2020 at 2:07 PM YU, Xiangning
> wrote:
>>
>>
>>
>> On 7/8/20 1:24 PM, Cong Wang wrote:
>>> On Tue, Jul 7, 2020 at 2:24 PM YU, Xiangning
>>> wrote:
The key is to avoid classifying packets from a same flow into different
class
On Fri, Jul 10, 2020 at 5:56 AM Jason Wang wrote:
>
>
> On 2020/7/10 上午1:37, Michael S. Tsirkin wrote:
> > On Thu, Jul 09, 2020 at 06:46:13PM +0200, Eugenio Perez Martin wrote:
> >> On Wed, Jul 1, 2020 at 4:10 PM Jason Wang wrote:
> >>>
> >>> On 2020/7/1 下午9:04, Eugenio Perez Martin wrote:
>
On Mon, Jul 06, 2020 at 08:01:28PM +0800, Xin Long wrote:
> Now ipip and ipv6 tunnels processing is supported by xfrm4/6_tunnel,
> but not in vti and xfrmi. This feature is needed by processing those
> uncompressed small fragments and packets when using comp protocol.
> It means vti and xfrmi won't
On Thu, Jul 9, 2020 at 10:04 PM Cong Wang wrote:
> IOW, without these *additional* efforts, it is broken in terms of
> out-of-order.
>
Take a look at fq_codel, it provides a hash function for flow classification,
fq_codel_hash(), as default, thus its default configuration does not
have such issue
On Wed, Jul 8, 2020 at 2:07 PM YU, Xiangning
wrote:
>
>
>
> On 7/8/20 1:24 PM, Cong Wang wrote:
> > On Tue, Jul 7, 2020 at 2:24 PM YU, Xiangning
> > wrote:
> >>
> >> The key is to avoid classifying packets from a same flow into different
> >> classes. So we use socket priority to classify packet
Trigger non-blocking busy poll when busy_poll is enabled and
epoll is called with a timeout of 0 and is associated with a
napi_id. This enables an app thread to go through napi poll
routine once by calling epoll with a 0 timeout.
poll/select with a 0 timeout behave in a similar manner.
Signed-o
On 2020/7/10 上午1:37, Michael S. Tsirkin wrote:
On Thu, Jul 09, 2020 at 06:46:13PM +0200, Eugenio Perez Martin wrote:
On Wed, Jul 1, 2020 at 4:10 PM Jason Wang wrote:
On 2020/7/1 下午9:04, Eugenio Perez Martin wrote:
On Wed, Jul 1, 2020 at 2:40 PM Jason Wang wrote:
On 2020/7/1 下午6:43, Eugen
From: Paul Blakey
After removing the tupleid register which changed per tuple,
tuple modify headers set the ct_state, zone, mark, and label registers.
For non-natted tuples going through the same tc rules path, their values
will be the same, and all their modify headers will be the same.
Re-use
From: Paul Blakey
Reg_c1 is 32 bits wide. Originally, 24 bit were allocated for the tuple_id,
6 bits for tunnel mapping and 2 bits for tunnel options mappings.
Restoring the ct state from zone lookup instead of tuple id requires
reg_c1 to store 8 bits mapping the ct zone, leaving 24 bits for tun
"flow" parameter is not used in __mlx5_tc_ct_flow_offload_clear(),
remove it.
Signed-off-by: Saeed Mahameed
Reviewed-by: Roi Dayan
---
drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core
From: Paul Blakey
Use a single byte mapping for zone restore register (zone matching
remains 16 bit).
This makes room for using the freed 8 bits on register C1 for
mapping more tunnels and tunnel options.
Signed-off-by: Paul Blakey
Reviewed-by: Oz Shlomo
Signed-off-by: Saeed Mahameed
---
..
From: Roi Dayan
Before this commit, on ft flush, ft entries were not removed
from the ct_tuple hashtables. Fix it.
Fixes: ac991b48d43c ("net/mlx5e: CT: Offload established flows")
Signed-off-by: Roi Dayan
Signed-off-by: Eli Britstein
Signed-off-by: Saeed Mahameed
---
.../ethernet/mellanox/ml
Instead of having to deal with converting between int and ERR_PTR for
return values in mlx5_tc_ct_flow_offload(), make the internal helper
functions return a ptr to mlx5_flow_handle instead of passing it as
output param, this will also avoid gcc confusion and false alarms,
thus we remove the redund
From: Paul Blakey
Refactor sharing of mod headers to new file and while there,
remove spin lock and flows list, as this is only used for warn on.
Use the generic API in the next patch to re-use tuple modify headers
for identical modify actions,
Signed-off-by: Paul Blakey
Reviewed-by: Roi Dayan
From: Paul Blakey
Remove tupleid, and replace it with zone_restore, which is the zone an
established tuple sets after match. On miss, Use this zone + tuple
taken from the skb, to lookup the ct entry and restore it.
This improves flow insertion rate by avoiding the allocation of a header
rewrite
From: Paul Blakey
Next patches will remove the tupleid registers that is used
to restore the ct state on miss, and instead use the tuple on
the missed packet to lookup which state to restore.
Disable tuple rewrites after connection tracking.
For tuple rewrites, inject a ct_state=-trk match so it
Hi Dave, Jakub,
This series provides updates to mlx5 CT (connection tracking) offloads
For more information please see tag log below.
Please pull and let me know if there is any problem.
The following conflict is expected when net is merged into net-next:
to resolve just use the hunks from net-n
From: Oz Shlomo
The next patch will pass the mlx5e_priv struct to the
modify_header_match_supported method. Use this opportunity to refactor
the existing pr_info call to a netdev_info call.
Signed-off-by: Oz Shlomo
Signed-off-by: Saeed Mahameed
---
drivers/net/ethernet/mellanox/mlx5/core/en_t
From: Paul Blakey
With ct clear we don't jump to the ct tables, so header rewrite
of 5-tuple can be done in place (and not moved to after the CT action).
Check for ct clear action, and if so, allow 5-tuple header
rewrite.
Signed-off-by: Paul Blakey
Reviewed-by: Oz Shlomo
Signed-off-by: Saeed
From: Parav Pandit
When eswitch is unsupported, currently -EPERM error code is returned
instead of -EOPNOTSUPP.
Due to this VF device's devlink virtual port is not enumerated because
port_function_get() callback returned -EPERM instead of -EOPNOTSUPP.
Hence, return the error code -EOPNOTSUPP wh
From: Paul Blakey
Save original tuple and natted tuple in two new hashtables.
This is a pre-step for restoring ct state after hw miss by performing a
5-tuple lookup on the hash tables.
Signed-off-by: Paul Blakey
Reviewed-by: Oz Shlomo
Signed-off-by: Saeed Mahameed
---
.../ethernet/mellanox/
On Thu, 9 Jul 2020 19:33:11 -0700 Tom Herbert wrote:
> The patch set looks good for its purpose, but, sorry, I can't resist
> another round of complaining about vendors that continue to develop
> protocol specific offloads instead of moving to protocol agnostic
> generic offloads.
I agree with all
Hi David,
The following pull-request contains BPF updates for your *net* tree.
We've added 4 non-merge commits during the last 1 day(s) which contain
a total of 4 files changed, 26 insertions(+), 15 deletions(-).
The main changes are:
1) fix crash in libbpf on 32-bit archs, from Jakub and Andri
The patch set looks good for its purpose, but, sorry, I can't resist
another round of complaining about vendors that continue to develop
protocol specific offloads instead of moving to protocol agnostic
generic offloads.
On Wed, Jul 8, 2020 at 6:19 PM Jakub Kicinski wrote:
>
> Kernel has a facili
From: Aya Levin
Some released FW versions mistakenly don't set the capability that 50G
per lane link-modes are supported for VFs (ptys_extended_ethernet
capability bit). When the capability is unset, read
PTYS.ext_eth_proto_capability (always reliable).
If PTYS.ext_eth_proto_capability is valid (
From: Eran Ben Elisha
Device unit for port buffers size, xoff_threshold and xon_threshold is
cells. Fix a bug in driver where cell unit size was hard-coded to
128 bytes. This hard-coded value is buggy, as it is wrong for some hardware
versions.
Driver to read cell size from SBCAM register and tr
From: Vlad Buslov
In mlx5e_configure_flower() flow pointer is protected by rcu read lock.
However, after cited commit the pointer is being used outside of rcu read
block. Extend the block to protect all pointer accesses.
Fixes: 553f9328385d ("net/mlx5e: Support tc block sharing for representors"
From: Aya Levin
After function reload, CPU mapping used by aRFS RX is broken, leading to
a kernel panic. Fix by moving initialization of rx_cpu_rmap from
netdev_init to netdev_attach. IRQ table is re-allocated on mlx5_load,
but netdev is not re-initialize.
Trace of the panic:
[ 22.055672] genera
From: Aya Levin
When detaching netdev, remove vxlan port configuration using
udp_tunnel_drop_rx_info. During function reload, configuration will be
restored using udp_tunnel_get_rx_info. This ensures sync between
firmware and driver. Use udp_tunnel_get_rx_info even if its physical
interface is do
From: Vlad Buslov
In helper function is_flow_rule_duplicate_allowed() verify that rpviv
pointer is not NULL before dereferencing it. This can happen when device is
in NIC mode and leads to following crash:
[90444.046419] BUG: kernel NULL pointer dereference, address:
[90444.0481
From: Eli Britstein
CT entries are deleted via a workqueue from netfilter. If removing the
module before that, the rules are cleaned by the driver itself, but the
memory entries for them are not freed. Fix that.
Fixes: ac991b48d43c ("net/mlx5e: CT: Offload established flows")
Signed-off-by: Eli
Hi Dave,
This series introduces some fixes to mlx5 driver.
V1->v2:
- Drop "ip -s" patch and mirred device hold reference patch.
- Will revise them in a later submission.
Please pull and let me know if there is any problem.
For -stable v5.2
('net/mlx5: Fix eeprom support for SFP module')
For
From: Eran Ben Elisha
Fix eeprom SFP query support by setting i2c_addr, offset and page number
correctly. Unlike QSFP modules, SFP eeprom params are as follow:
- i2c_addr is 0x50 for offset 0 - 255 and 0x51 for offset 256 - 511.
- Page number is always zero.
- Page offset is always relative to ze
From: Vu Pham
Refactoring eswitch ingress acl codes accidentally inserts extra
memset zero that removes vlan and/or qos setting in legacy mode.
Fixes: 07bab9502641 ("net/mlx5: E-Switch, Refactor eswitch ingress acl codes")
Signed-off-by: Vu Pham
Signed-off-by: Saeed Mahameed
---
drivers/net/e
On 7/9/20 12:25 AM, Hoang Huu Le wrote:
Fixes: 5027f233e35b ("tipc: add link broadcast get")
Signed-off-by: Hoang Huu Le
---
tipc/link.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tipc/link.c b/tipc/link.c
index ba77a20152ea..192736eaa154 100644
--- a/tipc/link.c
+
On Thu, 2020-07-09 at 12:47 -0700, Jakub Kicinski wrote:
> On Thu, 9 Jul 2020 15:20:11 -0300 Jason Gunthorpe wrote:
> > > 2) having the driver set RO on the transactions it initiates,
> > > which
> > >are honored iff the PCI bit is set.
> > >
> > > It seems that in addition to the PCI
On Thu, Jul 9, 2020 at 5:43 PM Jakub Kicinski wrote:
>
> Convert to new infra, taking advantage of sleeping in callbacks.
>
> v2:
> - use bp->*_fw_dst_port_id != INVALID_HW_RING_ID as indication
>that the offload is active.
>
> Signed-off-by: Jakub Kicinski
Reviewed-by: Michael Chan
Thank
On 7/9/20 3:22 PM, Eric Dumazet wrote:
>
>
> On 7/9/20 11:20 AM, YU, Xiangning wrote:
>>
>>
>> On 7/9/20 10:15 AM, Eric Dumazet wrote:
>>>
>>> Well, at Google we no longer have this issue.
>>>
>>> We adopted EDT model, so that rate limiting can be done in eBPF, by simply
>>> adjusting skb->ts
The 07/09/2020 15:26, Nikolay Aleksandrov wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 09/07/2020 13:00, Horatiu Vultur wrote:
> > Thie patch adds support for MRP Interconnect. Similar with the MRP ring,
> > if the HW can't generate
Coverity's static analysis helpfully reported a memory leak introduced by
0f0e55d8247c ("libbpf: Improve BTF sanitization handling"). While fixing it,
I realized that btf__new() already creates a memory copy, so there is no need
to do this. So this patch also fixes misleading btf__new() signature t
From: Julien Fortin
'bridge fdb get' has json support but the json object is never initialized
before patch:
$ bridge -j fdb get 56:23:28:4f:4f:e5 dev vx0
56:23:28:4f:4f:e5 dev vx0 master br0 permanent
$
after patch:
$ bridge -j fdb get 56:23:28:4f:4f:e5 dev vx0 | \
python -c \
'import sys,js
From: Julien Fortin
bridge json fdb show is printing an incorrect / non-machine readable
value, when using -j (json output) we are expecting machine readable
data that shouldn't require special handling/parsing.
$ bridge -j fdb show | \
python -c \
'import sys,json;print(json.dumps(json.loads(sy
It appears the clearing of UDP tunnel ports when RXCSUM
is disabled is unnecessary. Driver will not pay attention
to checksum bits if RXCSUM is not set, so we can let
the hardware parse the packets.
Note that the UDP tunnel port NDO handlers don't pay attention
to the state of RXCSUM, so the ports
debugfs_create_u32_array() allocates a small structure to wrap
the data and size information about the array. If users ever
try to remove the file this leads to a leak since nothing ever
frees this wrapper.
That said there are no upstream users of debugfs_create_u32_array()
that'd remove a u32 arr
Add validating the UDP tunnel infra works.
$ ./udp_tunnel_nic.sh
PASSED all 383 checks
Signed-off-by: Jakub Kicinski
---
.../drivers/net/netdevsim/udp_tunnel_nic.sh | 786 ++
1 file changed, 786 insertions(+)
create mode 100644
tools/testing/selftests/drivers/net/netdevsim/u
Add UDP tunnel port handlers to our fake driver so we can test
the core infra.
Signed-off-by: Jakub Kicinski
---
drivers/net/netdevsim/Makefile | 2 +-
drivers/net/netdevsim/dev.c | 1 +
drivers/net/netdevsim/netdev.c | 12 +-
drivers/net/netdevsim/netdevsim.h | 19 +++
Make it possible to use tunnel types as flags more easily.
There doesn't appear to be any user using the type as an
array index, so this should make no difference.
Signed-off-by: Jakub Kicinski
---
include/net/udp_tunnel.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a
Convert to new infra, taking advantage of sleeping in callbacks.
v2:
- use bp->*_fw_dst_port_id != INVALID_HW_RING_ID as indication
that the offload is active.
Signed-off-by: Jakub Kicinski
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 141 ++
drivers/net/ethernet/broa
Kernel has a facility to notify drivers about the UDP tunnel ports
so that devices can recognize tunneled packets. This is important
mostly for RX - devices which don't support CHECKSUM_COMPLETE can
report checksums of inner packets, and compute RSS over inner headers.
Some drivers also match the U
Make use of new common udp_tunnel_nic infra. ixgbe supports
IPv4 only, and only single VxLAN and Geneve ports (one each).
v2:
- split out the RXCSUM feature handling to separate change;
- declare structs separately;
- use ti.type instead of assuming table 0 is VxLAN;
- move setting netdev->udp
Add an interface to report offloaded UDP ports via ethtool netlink.
Now that core takes care of tracking which UDP tunnel ports the NICs
are aware of we can quite easily export this information out to
user space.
The responsibility of writing the netlink dumps is split between
ethtool code and ud
Cater to devices which:
(a) may want to sleep in the callbacks;
(b) only have IPv4 support;
(c) need all the programming to happen while the netdev is up.
Drivers attach UDP tunnel offload info struct to their netdevs,
where they declare how many UDP ports of various tunnel types
they support.
Convert to new infra, make use of the ability to sleep in the callback.
Signed-off-by: Jakub Kicinski
Acked-by: Tariq Toukan
---
.../net/ethernet/mellanox/mlx4/en_netdev.c| 107 --
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 2 -
2 files changed, 25 insertions(+), 84 d
On Thu, 9 Jul 2020 14:26:52 -0700 Jacob Keller wrote:
> The flash update for the ice hardware currently supports a single fixed
> configuration:
>
> * Firmware is always asked to preserve all changeable fields
> * The driver never allows downgrades
> * The driver will not allow canceling a previo
On Thu, 09 Jul 2020 16:32:35 -0700 (PDT) David Miller wrote:
> From: Cong Wang
>
> In order for no_refcnt and is_data to be the lowest order two
> bits in the 'val' we have to pad out the bitfield of the u8.
>
> Fixes: ad0f75e5f57c ("cgroup: fix cgroup_sk_alloc() for sk_clone_lock()")
> Reported
On Thu, Jul 9, 2020 at 4:32 PM David Miller wrote:
>
>
> From: Cong Wang
>
> In order for no_refcnt and is_data to be the lowest order two
> bits in the 'val' we have to pad out the bitfield of the u8.
>
> Fixes: ad0f75e5f57c ("cgroup: fix cgroup_sk_alloc() for sk_clone_lock()")
> Reported-by: Gu
On Thu, 9 Jul 2020 16:28:50 -0700 Jakub Kicinski wrote:
> v3:
> - fix build issue;
Ugh. The drivers need access to the stubs as well. Maybe:
+#ifdef CONFIG_INET
extern const struct udp_tunnel_nic_ops *udp_tunnel_nic_ops;
+#else
+#define udp_tunnel_nic_ops NULL
+#endif
On Fri, Jul 10, 2020 at 01:20:35AM +0200, Andrew Lunn wrote:
> > Virtualization is a reasonable use case in my opinion and it would
> > need something like this, for the guest kernel to have access to its
> > PHY.
>
> And i would like a better understanding of this use case. It seems odd
> you are
From: Cong Wang
In order for no_refcnt and is_data to be the lowest order two
bits in the 'val' we have to pad out the bitfield of the u8.
Fixes: ad0f75e5f57c ("cgroup: fix cgroup_sk_alloc() for sk_clone_lock()")
Reported-by: Guenter Roeck
Signed-off-by: David S. Miller
---
include/linux/cg
From: Mark Tomlinson
Date: Fri, 10 Jul 2020 11:27:34 +1200
> As background to this patch, we have MAXMIFS set to 1025 in our kernel.
This patch is pointless without that adjustment, so it really doesn't
belong upstream until you tackle the whole entire problem and therefore
make the limit able t
Add UDP tunnel port handlers to our fake driver so we can test
the core infra.
Signed-off-by: Jakub Kicinski
---
drivers/net/netdevsim/Makefile | 2 +-
drivers/net/netdevsim/dev.c | 1 +
drivers/net/netdevsim/netdev.c | 12 +-
drivers/net/netdevsim/netdevsim.h | 19 +++
Cater to devices which:
(a) may want to sleep in the callbacks;
(b) only have IPv4 support;
(c) need all the programming to happen while the netdev is up.
Drivers attach UDP tunnel offload info struct to their netdevs,
where they declare how many UDP ports of various tunnel types
they support.
Convert to new infra, taking advantage of sleeping in callbacks.
v2:
- use bp->*_fw_dst_port_id != INVALID_HW_RING_ID as indication
that the offload is active.
Signed-off-by: Jakub Kicinski
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 141 ++
drivers/net/ethernet/broa
Make use of new common udp_tunnel_nic infra. ixgbe supports
IPv4 only, and only single VxLAN and Geneve ports (one each).
v2:
- split out the RXCSUM feature handling to separate change;
- declare structs separately;
- use ti.type instead of assuming table 0 is VxLAN;
- move setting netdev->udp
It appears the clearing of UDP tunnel ports when RXCSUM
is disabled is unnecessary. Driver will not pay attention
to checksum bits if RXCSUM is not set, so we can let
the hardware parse the packets.
Note that the UDP tunnel port NDO handlers don't pay attention
to the state of RXCSUM, so the ports
Add validating the UDP tunnel infra works.
$ ./udp_tunnel_nic.sh
PASSED all 383 checks
Signed-off-by: Jakub Kicinski
---
.../drivers/net/netdevsim/udp_tunnel_nic.sh | 786 ++
1 file changed, 786 insertions(+)
create mode 100644
tools/testing/selftests/drivers/net/netdevsim/u
Add an interface to report offloaded UDP ports via ethtool netlink.
Now that core takes care of tracking which UDP tunnel ports the NICs
are aware of we can quite easily export this information out to
user space.
The responsibility of writing the netlink dumps is split between
ethtool code and ud
Convert to new infra, make use of the ability to sleep in the callback.
Signed-off-by: Jakub Kicinski
Acked-by: Tariq Toukan
---
.../net/ethernet/mellanox/mlx4/en_netdev.c| 107 --
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 2 -
2 files changed, 25 insertions(+), 84 d
Make it possible to use tunnel types as flags more easily.
There doesn't appear to be any user using the type as an
array index, so this should make no difference.
Signed-off-by: Jakub Kicinski
---
include/net/udp_tunnel.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a
debugfs_create_u32_array() allocates a small structure to wrap
the data and size information about the array. If users ever
try to remove the file this leads to a leak since nothing ever
frees this wrapper.
That said there are no upstream users of debugfs_create_u32_array()
that'd remove a u32 arr
Kernel has a facility to notify drivers about the UDP tunnel ports
so that devices can recognize tunneled packets. This is important
mostly for RX - devices which don't support CHECKSUM_COMPLETE can
report checksums of inner packets, and compute RSS over inner headers.
Some drivers also match the U
The function ip6mr_mfc_add() declared an array of ttls. If MAXMIFS is
large, this would create a large stack frame. This is fixed, and made
more efficient, by passing mf6cc_ifset to ip6mr_update_thresholds().
Signed-off-by: Mark Tomlinson
---
As background to this patch, we have MAXMIFS set to 1
From: Cong Wang
Date: Thu, 9 Jul 2020 12:19:40 -0700
> Make sure you test the second patch I sent, not the first one. The
> first one is still incomplete and ugly too. The two bits must be the
> last two, so correcting the if test is not sufficient, we have to
> fix the whole bitfield packing.
T
> Fear not, the lack of a mainline UAPI for MDIO access will not prevent
> any vendor from adding a sysfs mdio_read and mdio_write, if they need it
> for their user space SDK :)
They do. But it means you have to use their kernel, or at least their
kernel module. That will put off some people. But
On Thu, Jul 9, 2020 at 8:51 AM Jakub Sitnicki wrote:
>
> On Thu, Jul 09, 2020 at 06:23 AM CEST, Andrii Nakryiko wrote:
> > On Thu, Jul 2, 2020 at 2:25 AM Jakub Sitnicki wrote:
> >>
> >> Make libbpf aware of the newly added program type, and assign it a
> >> section name.
> >>
> >> Signed-off-by:
On Thu, Jul 9, 2020 at 6:25 AM Jakub Sitnicki wrote:
>
> On Thu, Jul 09, 2020 at 06:08 AM CEST, Andrii Nakryiko wrote:
> > On Thu, Jul 2, 2020 at 2:25 AM Jakub Sitnicki wrote:
> >>
> >> Add a new program type BPF_PROG_TYPE_SK_LOOKUP with a dedicated attach type
> >> BPF_SK_LOOKUP. The new program
On Thu, Jul 9, 2020 at 3:57 PM Andrii Nakryiko wrote:
>
> From: Jakub Bogusz
>
> On ILP32, 64-bit result was shifted by value calculated for 32-bit long type
> and returned value was much outside hashmap capacity.
> As advised by Andrii Nakryiko, this patch uses different hashing variant for
> ar
From: Jakub Bogusz
On ILP32, 64-bit result was shifted by value calculated for 32-bit long type
and returned value was much outside hashmap capacity.
As advised by Andrii Nakryiko, this patch uses different hashing variant for
architectures with size_t shorter than long long.
Fixes: e3b924224028
Hi Andrew,
On Fri, Jul 10, 2020 at 12:39:36AM +0200, Andrew Lunn wrote:
> On Thu, Jul 09, 2020 at 10:47:54PM +0200, Tobias Waldekranz wrote:
> > Hi netdev,
> >
> > TL;DR: Is something like https://github.com/wkz/mdio-tools a good
> > idea?
> >
> > The kernel does not, as far as I know, have a lo
> And, while we're at it: context switches from a VM to a host are
> expensive. And the PHY library polls around 5 MDIO registers per PHY
> every second.
Just wire up the interrupt. That stops all polling.
It would however be good to have details of what QEMU wants.
Andrew
On 7/9/20 3:30 AM, Hangbin Liu wrote:
This is a sample for xdp multicast. In the sample we could forward all
packets between given interfaces.
v5: add a null_map as we have strict the arg2 to ARG_CONST_MAP_PTR.
Move the testing part to bpf selftest in next patch.
v4: no update.
v3: add rxcn
On Thu, Jul 09, 2020 at 10:47:54PM +0200, Tobias Waldekranz wrote:
> Hi netdev,
>
> TL;DR: Is something like https://github.com/wkz/mdio-tools a good
> idea?
>
> The kernel does not, as far as I know, have a low-level debug
> interface to MDIO devices. I.e. something equivalent to i2c-dev or
> sp
On 7/9/20 3:30 AM, Hangbin Liu wrote:
This patch is for xdp multicast support. which has been discussed before[0],
The goal is to be able to implement an OVS-like data plane in XDP, i.e.,
a software switch that can forward XDP frames to multiple ports.
To achieve this, an application needs to sp
On 7/9/2020 1:47 PM, Tobias Waldekranz wrote:
> Hi netdev,
>
> TL;DR: Is something like https://github.com/wkz/mdio-tools a good
> idea?
>
> The kernel does not, as far as I know, have a low-level debug
> interface to MDIO devices. I.e. something equivalent to i2c-dev or
> spi-dev for example.
On Thu, Jul 09, 2020 at 10:00:42PM +0200, Jann Horn wrote:
> On Thu, Jul 9, 2020 at 8:26 PM Kees Cook wrote:
> > The sock counting (sock_update_netprioidx() and sock_update_classid())
> > was missing from pidfd's implementation of received fd installation. Add
> > a call to the new __receive_sock(
On 7/9/20 11:20 AM, YU, Xiangning wrote:
>
>
> On 7/9/20 10:15 AM, Eric Dumazet wrote:
>>
>> Well, at Google we no longer have this issue.
>>
>> We adopted EDT model, so that rate limiting can be done in eBPF, by simply
>> adjusting skb->tstamp.
>>
>> The qdisc is MQ + FQ.
>>
>> Stanislas Fom
Hi Tobias,
On Thu, Jul 09, 2020 at 10:47:54PM +0200, Tobias Waldekranz wrote:
> Hi netdev,
>
> TL;DR: Is something like https://github.com/wkz/mdio-tools a good
> idea?
>
> The kernel does not, as far as I know, have a low-level debug
> interface to MDIO devices. I.e. something equivalent to i2c
On Thu, Jul 9, 2020 at 5:49 AM Jakub Sitnicki wrote:
>
> On Thu, Jul 09, 2020 at 05:44 AM CEST, Andrii Nakryiko wrote:
> > On Thu, Jul 2, 2020 at 2:24 AM Jakub Sitnicki wrote:
> >>
> >> Extend the BPF netns link callbacks to rebuild (grow/shrink) or update the
> >> prog_array at given position wh
Hi netdev,
TL;DR: Is something like https://github.com/wkz/mdio-tools a good
idea?
The kernel does not, as far as I know, have a low-level debug
interface to MDIO devices. I.e. something equivalent to i2c-dev or
spi-dev for example. The closest thing I've found are the
SIOCG/SMIIREG ioctls, but t
1 - 100 of 317 matches
Mail list logo
