For BPF_MAP_TYPE_PERF_EVENT_ARRAY typically correct size is number of
possible CPUs. This is impossible to specify at compilation time. This
change adds automatic setting of PERF_EVENT_ARRAY size to number of
system CPUs, unless non-zero size is specified explicitly. This allows
to adjust size for
Add test verifying perf buffer API functionality.
Signed-off-by: Andrii Nakryiko
Acked-by: Song Liu
---
.../selftests/bpf/prog_tests/perf_buffer.c| 94 +++
.../selftests/bpf/progs/test_perf_buffer.c| 29 ++
2 files changed, 123 insertions(+)
create mode 100644 tools
BPF_MAP_TYPE_PERF_EVENT_ARRAY map is often used to send data from BPF program
to user space for additional processing. libbpf already has very low-level API
to read single CPU perf buffer, bpf_perf_event_read_simple(), but it's hard to
use and requires a lot of code to set everything up. This patch
Switch event_pipe implementation to rely on new libbpf perf buffer API
(it's raw low-level variant).
Signed-off-by: Andrii Nakryiko
---
tools/bpf/bpftool/map_perf_ring.c | 201 ++
1 file changed, 64 insertions(+), 137 deletions(-)
diff --git a/tools/bpf/bpftool/map_p
This patchset adds a high-level API for setting up and polling perf buffers
associated with BPF_MAP_TYPE_PERF_EVENT_ARRAY map. Details of APIs are
described in corresponding commit.
Patch #1 adds a set of APIs to set up and work with perf buffer.
Patch #2 enhances libbpf to support auto-setting PE
Re-sending as plain text, first time it somehow turned into HTML... :(
On Sat, Jun 29, 2019 at 11:24 AM Jakub Kicinski
wrote:
>
> On Fri, 28 Jun 2019 22:53:09 -0700, Andrii Nakryiko wrote:
> > map_info_len = sizeof(map_info);
> > map_fd = map_parse_fd_and_info(&argc, &argv, &map_info
From: Petr Machata
This register serves to configure global parameters of certain
monitoring operations. The following patches will use it to configure
that when PTP timestamps are delivered through the PTP FIFO traps, the
FIFO in question is cleared as well.
Signed-off-by: Petr Machata
Acked-b
From: Petr Machata
On Spectrum-1, timestamps for PTP packets are delivered through queues
of ingress and egress timestamps. There are two event traps
corresponding to activity on each of those queues. This mechanism is
absent on Spectrum-2, and therefore the traps should only be registered
on Spe
From: Petr Machata
The SIOCSHWTSTAMP ioctl configures HW timestamping on a given port.
Dispatch the ioctls to per-chip handler (which add to ptp_ops). Find
which PTP messages need to be timestamped and configure MTPPPC
accordingly.
The SIOCGHWTSTAMP ioctl is getter for the current configuration.
From: Petr Machata
The get_ts_info callback is used for obtaining information about
timestamping capabilities of a network device. On Spectrum-1, implement
it to advertise the PHC and the capability to do HW timestamping, and
the supported RX and TX filters.
Signed-off-by: Petr Machata
Acked-by
From: Petr Machata
On Spectrum-1, timestamped PTP packets and the corresponding timestamps
need to be kept in caches until both are available, at which point they are
matched up and packets forwarded as appropriate. However, not all packets
will ever see their timestamp, and not all timestamps wi
From: Ido Schimmel
This is the second patchset adding PTP support in mlxsw. Next patchset
will add PTP shapers which are required to maintain accuracy under rates
lower than 40Gb/s, while subsequent patchsets will add tracepoints and
selftests.
Petr says:
This patch set introduces support for r
From: Petr Machata
Add two ptp_ops: init and fini, to initialize and finalize the PTP
subsystem. Call as appropriate from mlxsw_sp_init() and _fini().
Lay the groundwork for Spectrum-1 support. On Spectrum-1, the received
timestamped packets and their corresponding timestamps arrive
independentl
From: Petr Machata
This register is used for configuring under which trap to deliver PTP
packets depending on type of the packet.
Signed-off-by: Petr Machata
Acked-by: Jiri Pirko
Signed-off-by: Ido Schimmel
---
drivers/net/ethernet/mellanox/mlxsw/reg.h | 39 +++
1 file ch
From: Petr Machata
On Spectrum-1, timestamps for PTP packets are delivered through queues
of ingress and egress timestamps. There are two event traps
corresponding to activity on each of those queues. This mechanism is
absent on Spectrum-2, and therefore the traps should only be registered
on Spe
From: Petr Machata
The MTPPTR is used for reading the per port PTP timestamp FIFO.
Signed-off-by: Petr Machata
Acked-by: Jiri Pirko
Signed-off-by: Ido Schimmel
---
drivers/net/ethernet/mellanox/mlxsw/reg.h | 110 ++
1 file changed, 110 insertions(+)
diff --git a/drivers/
From: Petr Machata
Up until now, the PTP hardware clock code was only invoked in the process
context (SYS_clock_adjtime -> do_clock_adjtime -> k_clock::clock_adj ->
pc_clock_adjtime -> posix_clock_operations::clock_adjtime ->
ptp_clock_info::adjtime -> mlxsw_spectrum).
In order to enable HW time
From: Petr Machata
On Spectrum-1, timestamps arrive through a pair of dedicated events:
MLXSW_TRAP_ID_PTP_ING_FIFO and _EGR_FIFO. The payload delivered with
those traps is contents of the timestamp FIFO at a given port in a given
direction. Add a Spectrum-1-specific handler for these two events w
From: Petr Machata
This register serves for configuration of which PTP messages should be
timestamped. This is a global configuration, despite the register name.
Signed-off-by: Petr Machata
Acked-by: Jiri Pirko
Signed-off-by: Ido Schimmel
---
drivers/net/ethernet/mellanox/mlxsw/reg.h | 38 ++
From: Petr Machata
The SKB control buffer is useful (and used) for bookkeeping of information
related to that SKB. Add helpers so that the mlxsw driver(s) can safely use
the buffer as well. The structure is currently empty, individual users will
add members to it as necessary.
Note that SKB allo
From: Petr Machata
Configure MTPTPT to set which message types should arrive under which
PTP trap, and MOGCR to clear the timestamp queue after its contents are
reported through PTP_ING_FIFO or PTP_EGR_FIFO.
With this configuration, PTP packets start arriving through the PTP
traps. However since
From: Petr Machata
On Spectrum-1, timestamps are delivered separately from the packets, and
need to paired up. Therefore, at some point after mlxsw_sp_port_xmit()
is invoked, it is necessary to involve the chip-specific driver code to
allow it to do the necessary bookkeeping and matching.
On Spe
From: Petr Machata
When configured, the Spectrum hardware can recognize PTP packets and
trap them to the CPU using dedicated traps, PTP0 and PTP1.
One reason to get PTP packets under dedicated traps is to have a
separate policer suitable for the amount of PTP traffic expected when
switch is oper
On 6/28/19 4:10 PM, Stanislav Fomichev wrote:
> Make sure that wide stores are allowed at proper (aligned) addresses.
> Note that user_ip6 is naturally aligned on 8-byte boundary, so
> correct addresses are user_ip6[0] and user_ip6[2]. msg_src_ip6 is,
> however, aligned on a 4-byte bondary, so on
On 6/28/19 4:10 PM, Stanislav Fomichev wrote:
> Since commit cd17d7770578 ("bpf/tools: sync bpf.h") clang decided
> that it can do a single u64 store into user_ip6[2] instead of two
> separate u32 ones:
>
> # 17: (18) r2 = 0x100
> # ; ctx->user_ip6[2] = bpf_htonl(DST_REWRITE_IP
On 30/06/2019 02:37, vto...@gmail.com wrote:
> On 30/06/2019 01:23, vto...@gmail.com wrote:
>> On 30/06/2019 01:11, Andrew Lunn wrote:
>>> On Sun, Jun 30, 2019 at 01:04:50AM +0200, vto...@googlemail.com wrote:
On 30/06/2019 00:49, Andrew Lunn wrote:
> On Sun, Jun 30, 2019 at 12:01:38AM +
On Tue, Jun 18, 2019 at 08:26:14PM +0300, Leon Romanovsky wrote:
> +static void __rdma_counter_dealloc(struct rdma_counter *counter)
> +{
> + mutex_lock(&counter->lock);
> + counter->device->ops.counter_dealloc(counter);
> + mutex_unlock(&counter->lock);
> +}
Does this lock do anythin
On 30/06/2019 01:23, vto...@gmail.com wrote:
> On 30/06/2019 01:11, Andrew Lunn wrote:
>> On Sun, Jun 30, 2019 at 01:04:50AM +0200, vto...@googlemail.com wrote:
>>> On 30/06/2019 00:49, Andrew Lunn wrote:
On Sun, Jun 30, 2019 at 12:01:38AM +0200, vto...@googlemail.com wrote:
> * DSA MV88E6
On Thu, Jun 27, 2019 at 6:37 AM John Hurley wrote:
>
> Skbs may have their checksum value populated by HW. If this is a checksum
> calculated over the entire packet then the CHECKSUM_COMPLETE field is
> marked. Changes to the data pointer on the skb throughout the network
> stack still try to main
On Tue, Jun 18, 2019 at 08:26:14PM +0300, Leon Romanovsky wrote:
> +/**
> + * rdma_counter_bind_qp_auto - Check and bind the QP to a counter base on
> + * the auto-mode rule
> + */
> +int rdma_counter_bind_qp_auto(struct ib_qp *qp, u8 port)
> +{
> + struct rdma_port_counter *port_counter;
>
Hi Heiner,
thanks for the speedy reply.
On 6/30/19 12:09 AM, Heiner Kallweit wrote:
> If r8169 (the mainline driver) is running, why do you want to switch
> to r8168 (the Realtek vendor driver)? The latter is not supported by
> the kernel community.
Well I did install r8168 because r8169 is not w
On Fri, Jun 28, 2019 at 12:05 PM Song Liu wrote:
>
> Hi Andy,
>
> > On Jun 27, 2019, at 4:40 PM, Andy Lutomirski wrote:
> >
> > On 6/27/19 1:19 PM, Song Liu wrote:
> >> This patch introduce unprivileged BPF access. The access control is
> >> achieved via device /dev/bpf. Users with write access t
On 30/06/2019 01:11, Andrew Lunn wrote:
> On Sun, Jun 30, 2019 at 01:04:50AM +0200, vto...@googlemail.com wrote:
>> On 30/06/2019 00:49, Andrew Lunn wrote:
>>> On Sun, Jun 30, 2019 at 12:01:38AM +0200, vto...@googlemail.com wrote:
* DSA MV88E6060
* iproute2 v.5.0.0-2.0
* OpenWRT 19.0
On Sun, Jun 30, 2019 at 01:04:50AM +0200, vto...@googlemail.com wrote:
>
> On 30/06/2019 00:49, Andrew Lunn wrote:
> > On Sun, Jun 30, 2019 at 12:01:38AM +0200, vto...@googlemail.com wrote:
> >> * DSA MV88E6060
> >> * iproute2 v.5.0.0-2.0
> >> * OpenWRT 19.07 with kernel 4.14.131 armv7l
> > The mv
> We have some tests under tools/testing/selftests/net/forwarding/, but
> not so much for MC. However, even if such tests were to be contributed,
> would you be able to run them on your hardware? I remember that in the
> past you complained about the number of required ports.
Hi Ido
Most devices
On 30/06/2019 00:49, Andrew Lunn wrote:
> On Sun, Jun 30, 2019 at 12:01:38AM +0200, vto...@googlemail.com wrote:
>> * DSA MV88E6060
>> * iproute2 v.5.0.0-2.0
>> * OpenWRT 19.07 with kernel 4.14.131 armv7l
> The mv88e6060 driver is very simple. It has no support for VLANs. It
> does not even have
On Sun, Jun 30, 2019 at 12:01:38AM +0200, vto...@googlemail.com wrote:
> * DSA MV88E6060
> * iproute2 v.5.0.0-2.0
> * OpenWRT 19.07 with kernel 4.14.131 armv7l
The mv88e6060 driver is very simple. It has no support for VLANs. It
does not even have support for offloading bridging between ports to
t
On 29.06.2019 22:34, Karsten Wiborg wrote:
> Hello,
>
> writing to you because of the r8168-dkms-README.Debian.
>
> I am using a GPD MicroPC running Debian Buster with Kernel:
> Linux praktifix 5.2.0-050200rc6-generic #201906222033 SMP Sun Jun 23
> 00:36:46 UTC 2019 x86_64 GNU/Linux
>
>
> Got t
* DSA MV88E6060
* iproute2 v.5.0.0-2.0
* OpenWRT 19.07 with kernel 4.14.131 armv7l
___
after
# bridge v a dev {bridge} self vid {n} untagged pvid
or with the device enslaved in the br
# bridge v a dev {device} vid {n} untagged pvid
I am hitting a roadblock when executing
# sysctl -w /sys/
On Fri, Jun 28, 2019 at 7:06 PM Matteo Croce wrote:
>
> On Fri, Jun 28, 2019 at 6:27 PM David Howells wrote:
> >
> > Nicolas Dichtel wrote:
> >
> > > David Howells was working on a mount notification mechanism:
> > > https://lwn.net/Articles/760714/
> > > https://git.kernel.org/pub/scm/linux/ker
Hi,
short update with some more data:
# more /var/lib/dkms/r8168/8.046.00/build/make.log
DKMS make.log for r8168-8.046.00 for kernel 5.2.0-050200rc6-generic (x86_64)
Sat 29 Jun 2019 10:11:15 PM CEST
make: Entering directory '/usr/src/linux-headers-5.2.0-050200rc6-generic'
CC [M] /var/lib/dkms/
On Fri, 2019-06-28 at 15:49 -0700, Jeff Kirsher wrote:
> This aligns the iavf_debug() macro with the other Intel drivers.
>
> Add the bus number, bus_id field to i40e_bus_info so output shows
> each physical port(i.e func) in following format:
> ]:]]:][][.[]]
> domains are numbered from 0 to
Hello,
writing to you because of the r8168-dkms-README.Debian.
I am using a GPD MicroPC running Debian Buster with Kernel:
Linux praktifix 5.2.0-050200rc6-generic #201906222033 SMP Sun Jun 23
00:36:46 UTC 2019 x86_64 GNU/Linux
Got the Kernel from:
https://kernel.ubuntu.com/~kernel-ppa/mainline/
On Sat, Jun 29, 2019 at 8:24 AM René van Dorst wrote:
>
> Both MTK_TRGMII_MT7621_CLK and MTK_PATH_BIT are defined as bit 10.
>
> This causes issues on non-MT7621 devices which has the
> MTK_PATH_BIT(MTK_ETH_PATH_GMAC1_RGMII) capability set.
> The wrong TRGMII setup code is executed.
>
> Moving the
From: Heiner Kallweit
Date: Thu, 27 Jun 2019 23:06:33 +0200
> The VLAN tag is stored in the descriptor in network byte order.
> Using swab16 works on little endian host systems only. Better play safe
> and use ntohs or htons respectively.
>
> Signed-off-by: Heiner Kallweit
Applied.
From: Heiner Kallweit
Date: Thu, 27 Jun 2019 23:12:39 +0200
> Documentation/DMA-API-HOWTO.txt states:
> By default, the kernel assumes that your device can address 32-bits of
> DMA addressing. For a 64-bit capable device, this needs to be increased,
> and for a device with limitations, it needs t
From: Heiner Kallweit
Date: Thu, 27 Jun 2019 23:19:09 +0200
> DMA_API_HOWTO.txt includes an example explaining when
> dma_sync_single_for_device() is not needed, and that example matches
> our use case. The buffer isn't changed by the CPU and direction is
> DMA_FROM_DEVICE, so we can remove the c
From: Mahesh Bandewar
Date: Thu, 27 Jun 2019 12:43:09 -0700
> +config TEST_BLACKHOLE_DEV
> + tristate "Test BPF filter functionality"
I think the tristate string needs to be changed :-)
From: Baruch Siach
Date: Thu, 27 Jun 2019 21:17:39 +0300
> Add a 1ms delay after reset deactivation. Otherwise the chip returns
> bogus ID value. This is observed with 88E6390 (Peridot) chip.
>
> Signed-off-by: Baruch Siach
> ---
> v2: Address Andrew Lunn's comments:
> Use usleep_range.
> D
From: "Guilherme G. Piccoli"
Date: Thu, 27 Jun 2019 13:31:33 -0300
> Currently bnx2x ptp worker tries to read a register with timestamp
> information in case of TX packet timestamping and in case it fails,
> the routine reschedules itself indefinitely. This was reported as a
> kworker always at 1
From: Florian Westphal
Date: Thu, 27 Jun 2019 17:12:42 +0200
> running the script on systems without netdevsim now prints:
>
> SKIP: ipsec_offload can't load netdevsim
>
> instead of error message & failed status.
>
> Signed-off-by: Florian Westphal
> ---
> Feel free to apply to -next, its n
Fixes: 30846090a746 ("xfrm: policy: add sequence count to sync with hash
resize")
Cc: Florian Westphal
Cc: Steffen Klassert
Signed-off-by: Cong Wang
---
net/xfrm/xfrm_policy.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index b1694d5d15
On Fri, 28 Jun 2019 14:39:29 -0700, Shannon Nelson wrote:
> +static int ionic_tx(struct queue *q, struct sk_buff *skb)
> +{
> + struct tx_stats *stats = q_to_tx_stats(q);
> + int err;
> +
> + if (skb->ip_summed == CHECKSUM_PARTIAL)
> + err = ionic_tx_calc_csum(q, skb);
> +
On Fri, 28 Jun 2019 14:39:31 -0700, Shannon Nelson wrote:
> Add in the detailed statistics for ethtool -S that the driver
> keeps as it processes packets. Display of the additional
> debug statistics can be enabled through the ethtool priv-flags
> feature.
>
> Signed-off-by: Shannon Nelson
> di
On Fri, 28 Jun 2019 14:39:32 -0700, Shannon Nelson wrote:
> @@ -1260,10 +1266,24 @@ static struct lif *ionic_lif_alloc(struct ionic
> *ionic, unsigned int index)
> if (err)
> goto err_out_free_lif_info;
>
> + /* allocate rss indirection table */
> + tbl_sz = le16_to_c
On Fri, 28 Jun 2019 14:39:19 -0700, Shannon Nelson wrote:
> @@ -64,4 +66,49 @@ int ionic_debugfs_add_ident(struct ionic *ionic)
> ionic, &identity_fops) ? 0 : -ENOTSUPP;
> }
>
> +int ionic_debugfs_add_sizes(struct ionic *ionic)
> +{
> + debugfs_create_u32("nl
On Fri, 28 Jun 2019 16:07:29 -0700, Catherine Sullivan wrote:
> This patch series adds the gve driver which will support the
> Compute Engine Virtual NIC that will be available in the future.
Looks like buildbot also found a bunch of bad endian casts.
Please make sure the driver builds with no war
On Fri, 28 Jun 2019 22:53:09 -0700, Andrii Nakryiko wrote:
> map_info_len = sizeof(map_info);
> map_fd = map_parse_fd_and_info(&argc, &argv, &map_info, &map_info_len);
> - if (map_fd < 0)
> + if (map_fd < 0) {
> + p_err("failed to get map info");
Can't do, map_parse
On Sat, 29 Jun 2019 19:55:08 +0200
Stefano Brivio wrote:
> Always increment the per-node counter by one if we previously dumped
> a regular route, so that it matches the current skip counter.
>
> Fixes: ee28906fd7a1 ("ipv4: Dump route exceptions if requested")
> Signed-off-by: Stefano Brivio
S
From: Eric Dumazet
Date: Thu, 27 Jun 2019 01:27:01 -0700
> im->tomb and/or im->sources might not be NULL, but we
> currently overwrite their values blindly.
>
> Using swap() will make sure the following call to kfree_pmc(pmc)
> will properly free the psf structures.
>
> Tested with the C repro
From: Nikolay Aleksandrov
Date: Thu, 27 Jun 2019 11:10:43 +0300
> We would like to be able to use the addrtype from tc for ACL rules and
> em_ipt seems the best place to add support for the already existing xt
> match. The biggest issue is that addrtype revision 1 (with ipv6 support)
> is NFPROTO
On Sat, Jun 29, 2019 at 11:04 AM Song Liu wrote:
>
> On Sat, Jun 29, 2019 at 7:43 AM Jiri Benc wrote:
> >
> > Selftests are reporting this failure in test_lwt_seg6local.sh:
> >
> > + ip netns exec ns2 ip -6 route add fb00::6 encap bpf in obj
> > test_lwt_seg6local.o sec encap_srh dev veth2
> > E
On Sat, Jun 29, 2019 at 7:43 AM Jiri Benc wrote:
>
> Selftests are reporting this failure in test_lwt_seg6local.sh:
>
> + ip netns exec ns2 ip -6 route add fb00::6 encap bpf in obj
> test_lwt_seg6local.o sec encap_srh dev veth2
> Error fetching program/map!
> Failed to parse eBPF program: Operati
From: Florian Westphal
Date: Wed, 26 Jun 2019 20:40:45 +0200
> netfilter did not expect that skb_dst_force() can cause skb to lose its
> dst entry.
>
> I got a bug report with a skb->dst NULL dereference in netfilter
> output path. The backtrace contains nf_reinject(), so the dst might have
> b
In commit ee28906fd7a1 ("ipv4: Dump route exceptions if requested") I
added a counter of per-node dumped routes (including actual routes and
exceptions), analogous to the existing counter for dumped nodes. Dumping
exceptions means we need to also keep track of how many routes are dumped
for each no
From: Xin Long
Date: Wed, 26 Jun 2019 16:31:39 +0800
> Now when sctp_connect() is called with a wrong sa_family, it binds
> to a port but doesn't set bp->port, then sctp_get_af_specific will
> return NULL and sctp_connect() returns -EINVAL.
>
> Then if sctp_bind() is called to bind to another po
On 2019-06-28 2:30 p.m., Roman Mashak wrote:
When adding or deleting a batch of entries, the kernel sends upto
TCA_ACT_MAX_PRIO entries in an event to user space. However it does not
consider that the action sizes may vary and require different skb sizes.
For example :
% cat tc-batch.sh
TC="sud
From: Catherine Sullivan
Date: Fri, 28 Jun 2019 16:07:33 -0700
> +void gve_get_channels(struct net_device *netdev, struct ethtool_channels
> *cmd)
...
> +int gve_set_channels(struct net_device *netdev, struct ethtool_channels *cmd)
...
> +void gve_get_ringparam(struct net_device *netdev,
> +
Hi Catherine,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Catherine-Sullivan/Add-gve-driver/20190629-143743
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-9) 7.4.0
On Sun, Jun 23, 2019 at 10:44:27AM +0300, Ido Schimmel wrote:
> On Sun, Jun 23, 2019 at 08:26:05AM +0100, Russell King - ARM Linux admin
> wrote:
> > On Sun, Jun 23, 2019 at 07:09:52AM +, Ido Schimmel wrote:
> > > When multicast snooping is enabled unregistered multicast traffic should
> > > o
On Sun, Jun 23, 2019 at 06:48:41AM +, Ido Schimmel wrote:
> On Thu, Jun 20, 2019 at 07:24:47PM -0700, Florian Fainelli wrote:
> > On 6/20/2019 4:56 PM, Vivien Didelot wrote:
> > > This patch adds support for enabling or disabling the flooding of
> > > unknown multicast traffic on the CPU ports,
In an earlier commit to improve NQ reservations on 57500 chips, we
set the resv_irqs on the 57500 VFs to the fixed value assigned by
the PF regardless of how many are actually used. The current
code assumes that resv_irqs minus the ones used by the network driver
must be the ones for the RDMA driv
After ethtool loopback packet tests, we re-open the nic for the next
IRQ test. If the open fails, we must not proceed with the IRQ test
or we will crash with NULL pointer dereference. Fix it by checking
the bnxt_open_nic() return code before proceeding.
Reported-by: Somasundaram Krishnasamy
Fix
Some firmware versions do not support this so use the silent variant
to send the message to firmware to suppress the harmless error. This
error message is unnecessarily alarming the user.
Fixes: afdc8a84844a ("bnxt_en: Add DCBNL DSCP application protocol support.")
Signed-off-by: Michael Chan
--
Miscellaneous bug fix patches, including two resource handling fixes for
the RDMA driver, a PCI shutdown patch to add pci_disable_device(), a patch
to fix ethtool selftest crash, and the last one suppresses an unnecessry
error message.
Please also queue patches 1, 2, and 3 for -stable. Thanks.
M
Some chips with older firmware can continue to perform DMA read from
context memory even after the memory has been freed. In the PCI shutdown
method, we need to call pci_disable_device() to shutdown DMA to prevent
this DMA before we put the device into D3hot. DMA memory request in
D3hot state wil
The current logic assumes that the RDMA driver uses one statistics
context adjacent to the ones used by the network driver. This
assumption is not true and the statistics context used by the
RDMA driver is tied to its MSIX base vector. This wrong assumption
can cause RDMA driver failure after cha
Hi Catherine,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Catherine-Sullivan/Add-gve-driver/20190629-143743
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-9) 7.4.0
Selftests are reporting this failure in test_lwt_seg6local.sh:
+ ip netns exec ns2 ip -6 route add fb00::6 encap bpf in obj
test_lwt_seg6local.o sec encap_srh dev veth2
Error fetching program/map!
Failed to parse eBPF program: Operation not permitted
The problem is __attribute__((always_inline))
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Catherine-Sullivan/gve-Add-basic-driver-framework-for-Compute-Engine-Virtual-NIC/20190629-161725
:: branch date: 6 hours ago
:: commit date: 6 hours ago
If you fix the issue, kindly add following
Ignore previous one or consider /27 as /25 at two places in previous mail:
***
I have a linux box with 2 interfaces with following IPs
eno1 : 10.1.1.0/24
eno2 : 192.168.2.0/25
I want to use network 10.3.3.0/25 as v
I have a linux box with 2 interfaces with following IPs
eno1 : 10.1.1.0/24
eno2 : 192.168.2.0/27
I want to use network 10.3.3.0/25 as virtual IPs for 192.168.2.0/25
i.e. I will be doing DNAT using NETMAP target of IPTABLES.
DNAT and NETMAP, etc. is not the issue.
For my requirement to work, main
Hi Catherine,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Catherine-Sullivan/Add-gve-driver/20190629-143743
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-rc1-7
This commit adds port parsing and port validate helper function to parse
single or range of port(s) from a given string. (e.g. 1234, 443-444)
Helpers will be used in prior to set target port(s) in samples/pktgen.
Signed-off-by: Daniel T. Lee
---
samples/pktgen/functions.sh | 34
Currently, kernel pktgen has the feature to specify udp destination port
for sending packet. (e.g. pgset "udp_dst_min 9")
But on samples, each of the scripts doesn't have any option to achieve this.
This commit adds the DST_PORT option to specify the target port(s) in the
script.
-p : ($DST
No reason to error out on a MT7621 device with DDR2 memory when non
TRGMII mode is selected.
Only MT7621 DDR2 clock setup is not supported for TRGMII mode.
But non TRGMII mode doesn't need any special clock setup.
Signed-off-by: René van Dorst
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7
Both MTK_TRGMII_MT7621_CLK and MTK_PATH_BIT are defined as bit 10.
This causes issues on non-MT7621 devices which has the
MTK_PATH_BIT(MTK_ETH_PATH_GMAC1_RGMII) capability set.
The wrong TRGMII setup code is executed.
Moving the MTK_PATH_BIT to bit 11 fixes the issue.
Fixes: 8efaa653a8a5 ("net:
Hi Catherine,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Catherine-Sullivan/Add-gve-driver/20190629-070444
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
On 6/28/19 11:06 PM, Jon Maloy wrote:
> The macro TIPC_BC_RETR_LIM is always used in combination with 'jiffies',
> so we can just as well perform the addition in the macro itself. This
> way, we get a few shorter code lines and one less line break.
>
> Signed-off-by: Jon Maloy
Acked-by: Ying Xue
On Sat, 29 Jun 2019 08:23:25 +0300
Ilias Apalodimas wrote:
> The interface only supports 1 Tx queue so locking is introduced on
> the Tx queue if XDP is enabled to make sure .ndo_start_xmit and
> .ndo_xdp_xmit won't corrupt Tx ring
>
> - Performance (SMMU off)
>
> Benchmark XDP_SKB XDP_DR
Hi Catherine,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Catherine-Sullivan/Add-gve-driver/20190629-070444
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
On Fri, Jun 28, 2019 at 10:55 PM Andrii Nakryiko wrote:
>
> For BPF_MAP_TYPE_PERF_EVENT_ARRAY typically correct size is number of
> possible CPUs. This is impossible to specify at compilation time. This
> change adds automatic setting of PERF_EVENT_ARRAY size to number of
> system CPUs, unless non
On Fri, Jun 28, 2019 at 8:49 PM Andrii Nakryiko wrote:
>
> Add ability to attach to kernel and user probes and retprobes.
> Implementation depends on perf event support for kprobes/uprobes.
>
> Signed-off-by: Andrii Nakryiko
Acked-by: Song Liu
On Fri, Jun 28, 2019 at 8:49 PM Andrii Nakryiko wrote:
>
> bpf_program__attach_perf_event allows to attach BPF program to existing
> perf event hook, providing most generic and most low-level way to attach BPF
> programs. It returns struct bpf_link, which should be passed to
> bpf_link__destroy to
94 matches
Mail list logo
