Harald Welte wrote:
> I believe _if_ one wants to use the approach of "hiding" eBPF behind
> iptables, then either
[..]
> b) you must introduce new 'tables', like an 'xdp' table which then has
>the notion of processing very early in processing, way before the
>normal filter table INPUT pro
Got it. I'll send an update.
donald
On Sat, Feb 17, 2018 at 6:35 PM, David Ahern wrote:
> On 2/17/18 5:47 AM, Donald Sharp wrote:
>> Fix iprule.c to use the actual `struct fib_rule_hdr` and to
>> allow the end user to see and use the protocol keyword
>> for rule manipulations.
>>
>> Donald Shar
In order to handle the number of rx sub crqs changing during a driver
reset, the ibmvnic driver also needs to update the number of napi.
To do this the code to init and free napi's is moved to their own
routines so they can be called during the reset process.
Signed-off-by: Nathan Fontenot
---
d
When the driver resets it is possible that the number of tx/rx
sub-crqs can change. This patch handles this so that the driver does
not try to access non-existent sub-crqs.
Additionally, a parameter is added to release_sub_crqs() so that
we know if the h_call to free the sub-crq needs to be made.
To avoid losing any stats when the number of sub-crqs change, allocate
the max number of stats buffers so a stats buffer exists all possible
sub-crqs.
Signed-off-by: Nathan Fontenot
---
drivers/net/ethernet/ibm/ibmvnic.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/
Inpreparation for using the active scrq count to track more active
resources, move the setting of the active count to after initialization
occurs in initial driver init and during driver reset.
Signed-off-by: Nathan Fontenot
---
drivers/net/ethernet/ibm/ibmvnic.c | 17 +++--
1 file
Rename the tx/rx active pool variables to be tx/rx active scrq
counts. The tx/rx pools are per sub-crq so this is a more appropriate
name. This also is a preparatory step for using thiese variables
for handling updates to sub-crqs and napi based on the active
count.
Signed-off-by: Nathan Fontenot
The ibmvnic driver needs to be able to handle the number of tx/rx
sub-crqs changing during a reset of the driver. To do this several
changes need to be made. First the num_active_[tx|rx]_pools
counters need to be re-named to num_active_[tc|rx]_scrqs, and
updated after resource initialization.
With
On 2/17/18 5:47 AM, Donald Sharp wrote:
> Fix iprule.c to use the actual `struct fib_rule_hdr` and to
> allow the end user to see and use the protocol keyword
> for rule manipulations.
>
> Donald Sharp (3):
> ip: Use the `struct fib_rule_hdr` for rules
> ip: Display ip rule protocol used
> i
> Note that this is a driver which is already in mainline, and I didn't
> write it. Claiming that *I* am doing this all wrong is a bit of a
> stretch - all this patch does is make small changes to some existing
> code, which only tangentially relates to a PHY driver, such that it
> ceases to be spe
Hi Andrew,
On Sat, Feb 17, 2018 at 11:29:33PM +0100, Andrew Lunn wrote:
> On Sat, Feb 17, 2018 at 12:10:25PM -0800, Paul Burton wrote:
> > The MIPS Boston development board uses the Intel EG20T Platform
> > Controller Hub, including its gigabit ethernet controller, and requires
> > that its RTL821
Florian Westphal wrote:
> David Miller wrote:
> > From: Florian Westphal
> > Date: Fri, 16 Feb 2018 17:14:08 +0100
> >
> > > Any particular reason why translating iptables rather than nftables
> > > (it should be possible to monitor the nftables changes that are
> > > announced by kernel and a
> @@ -0,0 +1,25 @@
> +Intel Platform Controller Hub (PCH) GigaBit Ethernet (GBE)
> +
> +Required properties:
> +- compatible:Should be the PCI vendor & device ID, eg.
> "pci8086,8802".
> +- reg: Should be a PCI device number as specified by
> the PCI bus
> +
On Sat, Feb 17, 2018 at 12:10:25PM -0800, Paul Burton wrote:
> The MIPS Boston development board uses the Intel EG20T Platform
> Controller Hub, including its gigabit ethernet controller, and requires
> that its RTL8211E PHY be reset much like the Minnow platform. Pull the
> PHY reset GPIO handling
On 17.02.2018 11:15, Dmitry Vyukov wrote:
> On Sat, Feb 17, 2018 at 4:00 AM, syzbot
> wrote:
>> Hello,
>>
>> syzbot hit the following crash on net-next commit
>> 65bd449c32c2745df61913ab54087e77f9d9b70d (Fri Feb 16 20:26:35 2018 +)
>> Merge branch 'tipc-de-generealize-topology-server'
>
> +ti
> @@ -2700,10 +2701,10 @@ static int pch_gbe_minnow_platform_init(struct
> pci_dev *pdev)
> return ret;
> }
>
> - gpio_set_value(gpio, 0);
> - usleep_range(1250, 1500);
> gpio_set_value(gpio, 1);
> usleep_range(1250, 1500);
> + gpio_set_value(gpio, 0);
Allow the ptp_pch driver to be built on MIPS platforms in preparation
for use on the MIPS Boston board.
Signed-off-by: Paul Burton
Acked-by: Richard Cochran
Cc: David S. Miller
Cc: linux-m...@linux-mips.org
Cc: netdev@vger.kernel.org
---
Changes in v5:
- Newly included in this series to satis
On weakly ordered systems writes to the RX or TX descriptors may be
reordered with the write to the DMA control register that enables DMA.
If this happens then the device may see descriptors in an intermediate
& invalid state, leading to incorrect behaviour. Add barriers to ensure
that DMA is enabl
The ethernet controller found in the Intel EG20T Platform Controller
Hub requires that we place 2 bytes of padding between the ethernet
header & the packet payload. Our pch_gbe driver handles this by copying
packets to be transmitted to a temporary struct skb with the padding
bytes inserted, howeve
On the MIPS Boston development board, the EG20T MAC does not report
receiving the RX clock from the (RGMII) RTL8211E PHY unless the PHY is
reset at the same time as the MAC. Since the pch_gbe driver resets the
MAC a number of times - twice during probe, and when taking down the
network interface -
Introduce documentation for a device tree binding for the Intel Platform
Controller Hub (PCH) GigaBit Ethernet (GBE) device. Although this is a
PCIe device & thus largely auto-detectable, this binding will be used to
provide the driver with the PHY reset GPIO.
Signed-off-by: Paul Burton
Cc: David
The pch_gbe driver splits configuration of the receive path between
pch_gbe_setup_rctl() & pch_gbe_configure_rx(), which are always called
together and in that order. The split between the two functions seems
somewhat arbitrary, as both are configuring registers for the receive
path. Fold pch_gbe_s
The pch_gbe_configure_rx() function open-codes the equivalent of
pch_gbe_disable_dma_rx(). Remove the duplication by moving
pch_gbe_disable_dma_rx(), and pch_gbe_enable_dma_rx() for consistency,
to be defined earlier than pch_gbe_configure_rx() and have
pch_gbe_configure_rx() call pch_gbe_disable_d
Allow the pch_gbe driver to be built on MIPS platforms, allowing its use
on the MIPS Boston development board.
Signed-off-by: Paul Burton
Cc: David S. Miller
Cc: linux-m...@linux-mips.org
Cc: netdev@vger.kernel.org
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
The pch_gbe driver enables TX DMA the first time we call
pch_gbe_configure_tx() and never disables it again, even if we
reconfigure the device & modify the transmit descriptor ring. This seems
unsafe, since the device may continue accessing descriptors whilst they
are in an unpredictable & possibly
Introduce support for retrieving the PHY reset GPIO from device tree,
which will be used on the MIPS Boston development board. This requires
support for probe deferral in order to work correctly, since the order
of device probe is not guaranteed & typically the EG20T GPIO controller
device will be
From: Hassan Naveed
Fix pch_gbe driver for ethernet operations for a big endian CPU.
Values written to and read from transmit and receive descriptors
in the pch_gbe driver are byte swapped from the perspective of a
big endian CPU, since the ethernet controller always operates in
little endian mod
The Intel EG20T Platform Controller Hub is used on the MIPS Boston
development board to provide various peripherals including ethernet.
This series fixes some issues with the pch_gbe driver discovered whilst
in use on the Boston board, and implements support for device tree which
we use to provide
Resets of the EG20T MAC on the MIPS Boston development board take longer
than the 1000 loops that pch_gbe_wait_clr_bit was performing. Rather
than simply increasing the number of loops, switch to using
readl_poll_timeout_atomic() from linux/iopoll.h in order to provide some
independence from the sp
The Minnow PHY reset GPIO is set to 0 to enter reset & 1 to leave reset
- that is, it is an active low GPIO. In order to allow for the code to
be made more generic by further patches, indicate to the GPIO subsystem
that the GPIO is active low & invert the values it is set to such that
they reflect
The MIPS Boston development board uses the Intel EG20T Platform
Controller Hub, including its gigabit ethernet controller, and requires
that its RTL8211E PHY be reset much like the Minnow platform. Pull the
PHY reset GPIO handling out of Minnow-specific code such that it can be
shared by later patc
> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Friday, February 16, 2018 21:33
> To: Jon Maloy
> Cc: netdev@vger.kernel.org; Mohan Krishna Ghanta Krishnamurthy
> ; Tung Quang Nguyen
> ; Hoang Huu Le
> ; Canh Duc Luu
> ; Ying Xue ; tipc-
> discuss...@lists.
David Miller wrote:
> From: Florian Westphal
> Date: Fri, 16 Feb 2018 17:14:08 +0100
>
> > Any particular reason why translating iptables rather than nftables
> > (it should be possible to monitor the nftables changes that are
> > announced by kernel and act on those)?
>
> As Daniel said, ipta
Daniel Borkmann wrote:
> Hi Florian,
>
> On 02/16/2018 05:14 PM, Florian Westphal wrote:
> > Florian Westphal wrote:
> >> Daniel Borkmann wrote:
> >> Several questions spinning at the moment, I will probably come up with
> >> more:
> >
> > ... and here there are some more ...
> >
> > One of t
On Sat, Feb 17, 2018 at 8:11 PM, Matteo Croce wrote:
> The IPVlan module currently depends on IPv6 and L3 Master dev.
> Refactor the code to allow building IPVlan module regardless of the value of
> CONFIG_IPV6 and CONFIG_NETFILTER, and change the CONFIG_NET_L3_MASTER_DEV
> dependency into a selec
IPVlan has an hard dependency on IPv6.
Refactor the ipvlan code to allow compiling it with IPv6 disabled.
Signed-off-by: Matteo Croce
---
drivers/net/Kconfig | 1 -
drivers/net/ipvlan/ipvlan_core.c | 71 ++--
drivers/net/ipvlan/ipvlan_main.c | 48
The IPVlan module currently depends on IPv6 and L3 Master dev.
Refactor the code to allow building IPVlan module regardless of the value of
CONFIG_IPV6 and CONFIG_NETFILTER, and change the CONFIG_NET_L3_MASTER_DEV
dependency into a select, as compiling L3 Master device alone has no sense.
$ grep -
The L3 Master device is just a glue between the core networking code and
device drivers, so it should be selected automatically rather than
requiring to be enabled explicitly.
Signed-off-by: Matteo Croce
---
drivers/net/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
On Sat, 2018-02-17 at 11:01 +0100, Oleksandr Natalenko wrote:
> Hi.
>
> On pátek 16. února 2018 23:59:52 CET Eric Dumazet wrote:
> > Well, no effect here on e1000e (1 Gbit) at least
> >
> > # ethtool -K eth3 sg off
> > Actual changes:
> > scatter-gather: off
> > tx-scatter-gather: off
> > tcp-se
On 02/16/2018 11:36 PM, Sargun Dhillon wrote:
> + close(111);
> + assert(errno == EBADF);
> + close(999);
> + assert(errno = EPERM);
should that be == ?
> +
> + return 0;
> +}
--
~Randy
Hi Jerome,
On Sat, Feb 17, 2018 at 5:41 PM, Jerome Brunet wrote:
> On Sat, 2018-02-17 at 15:08 +0100, Martin Blumenstingl wrote:
>> The common clock framework needs access to the "clock configuration"
>> structs during runtime.
>> However, only the common clock framework should access these. Ensu
On Fri, Feb 16, 2018 at 7:04 PM, Jakub Kicinski wrote:
> On Fri, 16 Feb 2018 10:11:21 -0800, Sridhar Samudrala wrote:
>> This patch enables virtio_net to switch over to a VF datapath when a VF
>> netdev is present with the same MAC address. It allows live migration
>> of a VM with a direct attache
On Fri, Feb 16, 2018 at 6:38 PM, Jakub Kicinski wrote:
> On Fri, 16 Feb 2018 10:11:19 -0800, Sridhar Samudrala wrote:
>> Ppatch 2 is in response to the community request for a 3 netdev
>> solution. However, it creates some issues we'll get into in a moment.
>> It extends virtio_net to use alterna
On Sat, 2018-02-17 at 15:08 +0100, Martin Blumenstingl wrote:
> The common clock framework needs access to the "clock configuration"
> structs during runtime.
> However, only the common clock framework should access these. Ensure
> this by moving the configuration structs out of struct meson8b_dwma
On Sat, 2018-02-17 at 15:08 +0100, Martin Blumenstingl wrote:
> To goal of this patch is to simplify the registration of the RGMII TX
> clock (and it's parent clocks). This is achieved by:
> - introducing the meson8b_dwmac_register_clk helper-function to remove
> code duplication when registering
Nothing in the dwmac-meson8b driver (except .probe itself) requires the
platform_device anymore after .probe has finished. Replace it with a
pointer to struct device since this is what the functions inside the
driver are actually accessing.
No functional changes.
Signed-off-by: Martin Blumenstingl
To goal of this patch is to simplify the registration of the RGMII TX
clock (and it's parent clocks). This is achieved by:
- introducing the meson8b_dwmac_register_clk helper-function to remove
code duplication when registering a single clock (this saves a few
lines since we have 4 clocks inter
The common clock framework needs access to the "clock configuration"
structs during runtime.
However, only the common clock framework should access these. Ensure
this by moving the configuration structs out of struct meson8b_dwmac,
so only meson8b_init_rgmii_tx_clk() and the common clock framework
This is a follow-up to my previous series "dwmac-meson8b: clock fixes for
Meson8b" from [0].
during the review of that series it was found that the clock registration
could be simplified. now that the previous series has landed we can start
cleaning up the clock registration.
the goal of this seri
Allow the specification of a protocol when the user
adds/modifies/deletes a rule.
Signed-off-by: Donald Sharp
---
ip/iprule.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/ip/iprule.c b/ip/iprule.c
index 5703d6e4..8fc6ac48 100644
--- a/ip/iprule.c
+++ b/ip/iprule.c
@@ -324,6 +324,12
The iprule.c code was using `struct rtmsg` as the data
type to pass into the kernel for the netlink message.
While 'struct rtmsg' and `struct fib_rule_hdr` are
the same size and mostly the same, we should use
the correct data structure. This commit translates
the data structures to have iprule.c u
Fix iprule.c to use the actual `struct fib_rule_hdr` and to
allow the end user to see and use the protocol keyword
for rule manipulations.
Donald Sharp (3):
ip: Use the `struct fib_rule_hdr` for rules
ip: Display ip rule protocol used
ip: Allow rules to accept a specified protocol
include/
Newer kernels are now accepting a protocol from the installing
program for who installed the rule. This change allows us
to see this change if it is being specified by the installing
program.
Signed-off-by: Donald Sharp
---
ip/iprule.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ip/i
Hi Daniel,
On Fri, Feb 16, 2018 at 02:40:19PM +0100, Daniel Borkmann wrote:
> This is a very rough and early proof of concept that implements bpfilter.
> The basic idea of bpfilter is that it can process iptables queries and
> translate them in user space into BPF programs which can then get attac
Hi Daniel,
On Fri, Feb 16, 2018 at 09:44:01PM +0100, Daniel Borkmann wrote:
> We started out with the
> iptables part in the demo as the majority of bigger infrastructure projects
> all still rely heavily on it (e.g. docker, k8s to just name two big ones).
docker is exec'ing the iptables command
Allow a rule that is being added/deleted/modified or
dumped to contain the originating protocol's id.
The protocol is handled just like a routes originating
protocol is. This is especially useful because there
is starting to be a plethora of different user space
programs adding rules.
Signed-off
Allow the vrf device to specify that the kernel is the originator
of the rule created for this device.
Signed-off-by: Donald Sharp
---
drivers/net/vrf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index 139c61c8244a..ec6d2d623b60 100644
--- a/drivers
Add the ability for the kernel to track the originating protocol
for when new rules are added to the kernel.
Donald Sharp (2):
net: Allow a rule to track originating protocol
drivers: Modify vrf device to specify it's rule as RTPROT_KERNEL
drivers/net/vrf.c | 1 +
include/net/fi
Hi David,
On Fri, Feb 16, 2018 at 05:33:54PM -0500, David Miller wrote:
> From: Florian Westphal
>
> > Any particular reason why translating iptables rather than nftables
> > (it should be possible to monitor the nftables changes that are
> > announced by kernel and act on those)?
>
> As Danie
Hi.
On pátek 16. února 2018 23:59:52 CET Eric Dumazet wrote:
> Well, no effect here on e1000e (1 Gbit) at least
>
> # ethtool -K eth3 sg off
> Actual changes:
> scatter-gather: off
> tx-scatter-gather: off
> tcp-segmentation-offload: off
> tx-tcp-segmentation: off [requested on]
> tx-tcp6-segmen
Hello!
On 2/16/2018 7:10 PM, Niklas Söderlund wrote:
Allow for changing the MTU within the limit of the maximum size of a
descriptor (2048 bytes). Add the callback to change MTU from user-space
and take the configurable MTU into account when configuring the
hardware.
Signed-off-by: Niklas Söde
61 matches
Mail list logo
