Re: [PATCH v2 net-next] net: remove bypassed check in sch_direct_xmit()

From: Song Liu Date: Tue, 29 May 2018 10:03:21 -0700 > Checking netif_xmit_frozen_or_stopped() at the end of sch_direct_xmit() > is being bypassed. This is because "ret" from sch_direct_xmit() will be > either NETDEV_TX_OK or NETDEV_TX_BUSY, and only ret == NETDEV_TX_OK == 0 > will reach the

[PATCH v2 net-next] net: remove bypassed check in sch_direct_xmit()

Checking netif_xmit_frozen_or_stopped() at the end of sch_direct_xmit() is being bypassed. This is because "ret" from sch_direct_xmit() will be either NETDEV_TX_OK or NETDEV_TX_BUSY, and only ret == NETDEV_TX_OK == 0 will reach the condition: if (ret && netif_xmit_frozen_or_stopped(txq))

Re: [PATCH v2 net-next] net:sched: add action inheritdsfield to skbedit

On 28/05/18 11:42 AM, Marcelo Ricardo Leitner wrote: On Mon, May 28, 2018 at 05:40:18AM +, Fu, Qiaobin wrote: The new action inheritdsfield copies the field DS of IPv4 and IPv6 packets into skb->priority. This enables later classification of packets based on the DS field. Original idea by

Re: [PATCH v2 net-next] net:sched: add action inheritdsfield to skbedit

On Mon, May 28, 2018 at 05:40:18AM +, Fu, Qiaobin wrote: > The new action inheritdsfield copies the field DS of > IPv4 and IPv6 packets into skb->priority. This enables > later classification of packets based on the DS field. > > Original idea by Jamal Hadi Salim > >

[PATCH v2 net-next] net:sched: add action inheritdsfield to skbedit

The new action inheritdsfield copies the field DS of IPv4 and IPv6 packets into skb->priority. This enables later classification of packets based on the DS field. Original idea by Jamal Hadi Salim Signed-off-by: Qiaobin Fu Reviewed-by: Michel Machado

Re: [PATCH v2 net-next] tcp: use data length instead of skb->len in tcp_probe

> On May 25, 2018, at 3:14 AM, Yafang Shao wrote: > > skb->len is meaningless to user. > data length could be more helpful, with which we can easily filter out > the packet without payload. > > Signed-off-by: Yafang Shao Acked-by: Song Liu

Re: [PATCH v2 net-next] sfc: stop the TX queue before pushing new buffers

From: Martin Habets Date: Thu, 24 May 2018 10:14:00 +0100 > efx_enqueue_skb() can push new buffers for the xmit_more functionality. > We must stops the TX queue before this or else the TX queue does not get > restarted and we get a netdev watchdog. > > In the error

Re: [PATCH v2 net-next] net: stmmac: Add PPS and Flexible PPS support

On Fri, May 25, 2018 at 04:32:52PM +0100, Jose Abreu wrote: > +int dwmac5_pps_config(void __iomem *ioaddr, bool enable) > +{ > + u32 val = readl(ioaddr + MAC_PPS_CONTROL); > + > + /* There is no way to disable fixed PPS output so we just reset > + * the values to make sure its in

[PATCH v2 net-next] net: stmmac: Add PPS and Flexible PPS support

This adds support for PPS output and Flexible PPS (which is equivalent to per_out output of PTP subsystem). Tested using an oscilloscope and the following commands: 1) Start PTP4L: # ptp4l -A -4 -H -m -i eth0 & 2) Set Flexible PPS frequency: # echo >

Re: [PATCH v2 net-next] sfc: stop the TX queue before pushing new buffers

On 24/05/18 10:14, Martin Habets wrote: > efx_enqueue_skb() can push new buffers for the xmit_more functionality. > We must stops the TX queue before this or else the TX queue does not get > restarted and we get a netdev watchdog. > > In the error handling we may now need to unwind more than 1

[PATCH v2 net-next] tcp: use data length instead of skb->len in tcp_probe

skb->len is meaningless to user. data length could be more helpful, with which we can easily filter out the packet without payload. Signed-off-by: Yafang Shao --- include/trace/events/tcp.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

Re: [PATCH v2 net-next 0/3] net: Update fib_table_lookup tracepoints

From: dsah...@kernel.org Date: Wed, 23 May 2018 17:08:46 -0700 > From: David Ahern > > Update the FIB lookup tracepoints to include ip proto and port fields > from the flow struct. In the process make the IPv4 tracepoint inline > with IPv6 which is much easier to use and

[PATCH v2 net-next] sfc: stop the TX queue before pushing new buffers

efx_enqueue_skb() can push new buffers for the xmit_more functionality. We must stops the TX queue before this or else the TX queue does not get restarted and we get a netdev watchdog. In the error handling we may now need to unwind more than 1 packet, and we may need to push the new buffers onto

[PATCH v2 net-next 2/3] net/ipv6: Udate fib6_table_lookup tracepoint

From: David Ahern Commit bb0ad1987e96 ("ipv6: fib6_rules: support for match on sport, dport and ip proto") added support for protocol and ports to FIB rules. Update the FIB lookup tracepoint to dump the parameters. Signed-off-by: David Ahern ---

[PATCH v2 net-next 0/3] net: Update fib_table_lookup tracepoints

From: David Ahern Update the FIB lookup tracepoints to include ip proto and port fields from the flow struct. In the process make the IPv4 tracepoint inline with IPv6 which is much easier to use and follow the lookup and result. Remove the tracepoint in fib_validate_source

[PATCH v2 net-next 3/3] net/ipv4: Remove tracepoint in fib_validate_source

From: David Ahern Tracepoint does not add value and the call to fib_lookup follows it which shows the same information and the fib lookup result. Signed-off-by: David Ahern --- include/trace/events/fib.h | 35 ---

[PATCH v2 net-next 1/3] net/ipv4: Udate fib_table_lookup tracepoint

From: David Ahern Commit 4a2d73a4fb36 ("ipv4: fib_rules: support match on sport, dport and ip proto") added support for protocol and ports to FIB rules. Update the FIB lookup tracepoint to dump the parameters. In addition, make the IPv4 tracepoint similar to the IPv6 one

Re: [PATCH v2 net-next] net: stmmac: Populate missing callbacks in HWIF initialization

From: Jose Abreu Date: Fri, 18 May 2018 16:54:38 +0100 > Some HW specific setups, like sun8i, do not populate all the necessary > callbacks, which is what HWIF helpers were expecting. > > Fix this by always trying to get the generic helpers and populate them > if they

[PATCH v2 net-next] net: stmmac: Populate missing callbacks in HWIF initialization

Some HW specific setups, like sun8i, do not populate all the necessary callbacks, which is what HWIF helpers were expecting. Fix this by always trying to get the generic helpers and populate them if they were not previously populated by HW specific setup. Signed-off-by: Jose Abreu

Re: [PATCH v2 net-next 00/12] net: stmmac: Clean-up and tune-up

Hi David, On 17-05-2018 19:47, David Miller wrote: > From: David Miller > Date: Thu, 17 May 2018 14:41:17 -0400 (EDT) > >> From: Jose Abreu >> Date: Thu, 17 May 2018 14:24:42 +0100 >> >>> Given that the difference between better/worst is < 1%, I

Re: [PATCH v2 net-next 3/6] tcp: add SACK compression

On 05/17/2018 10:47 AM, Eric Dumazet wrote: > + /* compress ack timer : 5 % of srtt, but no more than 1 ms */ > + > + delay = min_t(unsigned long, NSEC_PER_MSEC, > + tp->rcv_rtt_est.rtt_us * (NSEC_PER_USEC >> 3)/20); > Yuchung suggested that we use min(rtt, rcv_rtt),

Re: [PATCH v2 net-next 00/12] net: stmmac: Clean-up and tune-up

From: David Miller Date: Thu, 17 May 2018 14:41:17 -0400 (EDT) > From: Jose Abreu > Date: Thu, 17 May 2018 14:24:42 +0100 > >> Given that the difference between better/worst is < 1%, I think >> we can conclude patches 3-13 don't affect the overall

Re: [PATCH v2 net-next 00/12] net: stmmac: Clean-up and tune-up

From: Jose Abreu Date: Thu, 17 May 2018 14:24:42 +0100 > Given that the difference between better/worst is < 1%, I think > we can conclude patches 3-13 don't affect the overall > performance. I didn't profile the cache hits/miss though ... Ok, thanks for making an

[PATCH v2 net-next 6/6] tcp: add tcp_comp_sack_nr sysctl

This per netns sysctl allows for TCP SACK compression fine-tuning. This limits number of SACK that can be compressed. Using 0 disables SACK compression. Signed-off-by: Eric Dumazet --- Documentation/networking/ip-sysctl.txt | 6 ++ include/net/netns/ipv4.h

[PATCH v2 net-next 4/6] tcp: add TCPAckCompressed SNMP counter

This counter tracks number of ACK packets that the host has not sent, thanks to ACK compression. Sample output : $ nstat -n;sleep 1;nstat|egrep "IpInReceives|IpOutRequests|TcpInSegs|TcpOutSegs|TcpExtTCPAckCompressed" IpInReceives123250 0.0 IpOutRequests

[PATCH v2 net-next 3/6] tcp: add SACK compression

When TCP receives an out-of-order packet, it immediately sends a SACK packet, generating network load but also forcing the receiver to send 1-MSS pathological packets, increasing its RTX queue length/depth, and thus processing time. Wifi networks suffer from this aggressive behavior, but

[PATCH v2 net-next 5/6] tcp: add tcp_comp_sack_delay_ns sysctl

This per netns sysctl allows for TCP SACK compression fine-tuning. Its default value is 1,000,000, or 1 ms to meet TSO autosizing period. Signed-off-by: Eric Dumazet --- Documentation/networking/ip-sysctl.txt | 7 +++ include/net/netns/ipv4.h | 1 +

[PATCH v2 net-next 2/6] tcp: do not force quickack when receiving out-of-order packets

As explained in commit 9f9843a751d0 ("tcp: properly handle stretch acks in slow start"), TCP stacks have to consider how many packets are acknowledged in one single ACK, because of GRO, but also because of ACK compression or losses. We plan to add SACK compression in the following patch, we must

[PATCH v2 net-next 0/6] tcp: implement SACK compression

When TCP receives an out-of-order packet, it immediately sends a SACK packet, generating network load but also forcing the receiver to send 1-MSS pathological packets, increasing its RTX queue length/depth, and thus processing time. Wifi networks suffer from this aggressive behavior, but

[PATCH v2 net-next 1/6] tcp: use __sock_put() instead of sock_put() in tcp_clear_xmit_timers()

Socket can not disappear under us. Signed-off-by: Eric Dumazet Acked-by: Neal Cardwell --- include/net/tcp.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/net/tcp.h b/include/net/tcp.h index

Re: [PATCH v2 net-next 00/12] net: stmmac: Clean-up and tune-up

Hi David, Florian, Results of slowing down CPU follows bellow. On 16-05-2018 20:01, Florian Fainelli wrote: > On 05/16/2018 11:56 AM, David Miller wrote: >> From: Jose Abreu >> Date: Wed, 16 May 2018 13:50:42 +0100 >> >>> David raised some rightfull constrains about the

Re: [PATCH v2 net-next 00/12] net: stmmac: Clean-up and tune-up

On 05/16/2018 11:56 AM, David Miller wrote: > From: Jose Abreu > Date: Wed, 16 May 2018 13:50:42 +0100 > >> David raised some rightfull constrains about the use of indirect callbacks in >> the code. I did iperf tests with and without patches 3-12 and the performance >>

Re: [PATCH v2 net-next 00/12] net: stmmac: Clean-up and tune-up

From: Jose Abreu Date: Wed, 16 May 2018 13:50:42 +0100 > David raised some rightfull constrains about the use of indirect callbacks in > the code. I did iperf tests with and without patches 3-12 and the performance > remained equal. I guess for 1Gb/s and because my setup

[PATCH v2 net-next 01/12] net: stmmac: Enable OSP for GMAC4

This enables OSP (Operate on Second Packet) for GMAC4. The feature allows DMA to fetch second descriptor while its still processing the first one. Running iperf, the performance gain is +/- 38%. Signed-off-by: Jose Abreu Cc: David S. Miller Cc: Joao

[PATCH v2 net-next 02/12] net: stmmac: Do not keep rearming the coalesce timer in stmmac_xmit

This is cutting down performance. Once the timer is armed it should run after the time expires for the first packet sent and not the last one. After this change, running iperf, the performance gain is +/- 24%. Signed-off-by: Jose Abreu Cc: David S. Miller

[PATCH v2 net-next 06/12] net: stmmac: Remove uneeded checks for GMAC version

With the introducion of callbacks check in hwif.h we only call the callback if HW supports it so there is no longer need to check for GMAC version. Signed-off-by: Jose Abreu Cc: David S. Miller Cc: Joao Pinto Cc: Vitor Soares

[PATCH v2 net-next 05/12] net: stmmac: Uniformize the use of dma_{rx/tx}_mode callbacks

Instead of relying on the GMAC version for choosing if we need to use dma_{rx/tx}_mode or just dma_mode callback lets uniformize this and always use the dma_{rx/tx}_mode callbacks. Signed-off-by: Jose Abreu Cc: David S. Miller Cc: Joao Pinto

[PATCH v2 net-next 03/12] net: stmmac: Let descriptor code set skbuff address

Stop using if conditions depending on the GMAC version for setting the the descriptor skbuff address and use instead a helper implemented in the descriptor files. Signed-off-by: Jose Abreu Cc: David S. Miller Cc: Joao Pinto Cc:

[PATCH v2 net-next 09/12] net: stmmac: Remove uneeded check for GMAC version in stmmac_xmit

We either have .enable_dma_transmission or .set_tx_tail_ptr in the HW table callbacks, we can never have both so there is no need to check for GMAC version. Signed-off-by: Jose Abreu Cc: David S. Miller Cc: Joao Pinto Cc: Vitor

[PATCH v2 net-next 10/12] net: stmmac: Uniformize set_rx_owner()

Currently an if condition is used to select the correct callback to set rx_onwer in descriptor. Lets keep this simple and always use the same callback. Signed-off-by: Jose Abreu Cc: David S. Miller Cc: Joao Pinto Cc: Vitor Soares

[PATCH v2 net-next 12/12] net: stmmac: Remove if condition by taking advantage of hwif return code

We can remove the if condition and check if return code is different than -EINVAL, meaning callback is present. Signed-off-by: Jose Abreu Cc: David S. Miller Cc: Joao Pinto Cc: Vitor Soares Cc: Giuseppe

[PATCH v2 net-next 11/12] net: stmmac: Let descriptor code get skbuff address

Stop using if conditions depending on the GMAC version for getting the descriptor skbuff address and use instead a helper implemented in the descriptor files. Signed-off-by: Jose Abreu Cc: David S. Miller Cc: Joao Pinto Cc: Vitor

[PATCH v2 net-next 08/12] net: stmmac: Uniformize the use of dma_init_* callbacks

Instead of relying on the GMAC version for choosing if we need to use dma_init or dma_init_{rx/tx}_chan callback, lets uniformize this and always use the dma_init_{rx/tx}_chan callbacks. While at it, fix the use of dma_init_chan callback, which shall be called for as many channels as the max of

[PATCH v2 net-next 07/12] net: stmmac: Move PTP and MMC base address calculation to hwif.c

PTP and MMC modules base address can depend on the GMAC version. As this is HW specific lets move this base address calculation to hwif.c. Also, add an entry in the HW table so that we can specify the module offset. This can later be extended to more modules, if deemed necessary. Signed-off-by:

[PATCH v2 net-next 00/12] net: stmmac: Clean-up and tune-up

This targets to uniformize the handling of the different GMAC versions in stmmac_main.c file and also tune-up the HW. Currently there are some if/else conditions in the main source file which calls different callbacks depending on the ID of GMAC. With the introducion of a generic HW interface

[PATCH v2 net-next 04/12] net: stmmac: Let descriptor code clear the descriptor

Stop using if conditions depending on the GMAC version for clearing the descriptor and use instead a helper implemented in the descriptor files. Signed-off-by: Jose Abreu Cc: David S. Miller Cc: Joao Pinto Cc: Vitor Soares

Re: [PATCH v2 net-next] tcp: switch pacing timer to softirq based hrtimer

From: Eric Dumazet Date: Thu, 10 May 2018 14:59:43 -0700 > linux-4.16 got support for softirq based hrtimers. > TCP can switch its pacing hrtimer to this variant, since this > avoids going through a tasklet and some atomic operations. > > pacing timer logic looks like other

Re: [PATCH v2 net-next 1/4] umh: introduce fork_usermode_blob() helper

On Thu, May 10, 2018 at 03:27:24PM -0700, Kees Cook wrote: > On Fri, May 4, 2018 at 12:56 PM, Luis R. Rodriguez wrote: > > What a mighty short list of reviewers. Adding some more. My review below. > > I'd appreciate a Cc on future versions of these patches. > > Me too, please.

Re: [PATCH v2 net-next 1/4] umh: introduce fork_usermode_blob() helper

On Fri, May 4, 2018 at 12:56 PM, Luis R. Rodriguez wrote: > What a mighty short list of reviewers. Adding some more. My review below. > I'd appreciate a Cc on future versions of these patches. Me too, please. And likely linux-security-module@ and Jessica too. > On Wed, May

[PATCH v2 net-next] tcp: switch pacing timer to softirq based hrtimer

linux-4.16 got support for softirq based hrtimers. TCP can switch its pacing hrtimer to this variant, since this avoids going through a tasklet and some atomic operations. pacing timer logic looks like other (jiffies based) tcp timers. v2: use hrtimer_try_to_cancel() in tcp_clear_xmit_timers()

Re: [PATCH v2 net-next] drivers: net: davinci_mdio: prevent spurious timeout

On Wednesday 09 May 2018 07:00 PM, Andrew Lunn wrote: > On Wed, May 09, 2018 at 04:30:24PM +0530, Sekhar Nori wrote: >> A well timed kernel preemption in the time_after() loop >> in wait_for_idle() can result in a spurious timeout >> error to be returned. >> >> Fix it by using readl_poll_timeout()

Re: [PATCH v2 net-next] drivers: net: davinci_mdio: prevent spurious timeout

On Wed, May 09, 2018 at 04:30:24PM +0530, Sekhar Nori wrote: > A well timed kernel preemption in the time_after() loop > in wait_for_idle() can result in a spurious timeout > error to be returned. > > Fix it by using readl_poll_timeout() which takes care of > this issue. > > Signed-off-by:

[PATCH v2 net-next] drivers: net: davinci_mdio: prevent spurious timeout

A well timed kernel preemption in the time_after() loop in wait_for_idle() can result in a spurious timeout error to be returned. Fix it by using readl_poll_timeout() which takes care of this issue. Signed-off-by: Sekhar Nori --- v2: use readl_poll_timeout() per suggestion from

Re: [PATCH v2 net-next 2/4] net: add skeleton of bpfilter kernel module

On Mon, May 07, 2018 at 06:51:24PM +, Luis R. Rodriguez wrote: > > Notice that _binary_net_bpfilter_bpfilter_umh_start - end > > is placed into .init.rodata section, so it's freed as soon as __init > > function of bpfilter.ko is finished. > > As part of __init the bpfilter.ko does first

Re: [PATCH v2 net-next 1/4] umh: introduce fork_usermode_blob() helper

On Mon, May 07, 2018 at 06:39:31PM +, Luis R. Rodriguez wrote: > > > Are you saying make 'static struct vfsmount *shm_mnt;' > > global and use it here? so no init_tmpfs() necessary? > > I think that can work, but feels that having two > > tmpfs mounts (one for shmem and one for umh) is

Re: [PATCH V2 net-next] liquidio: support use of ethtool to set link speed of CN23XX-225 cards

From: Felix Manlunas Date: Fri, 4 May 2018 11:07:19 -0700 > From: Weilin Chang > > Support setting the link speed of CN23XX-225 cards (which can do 25Gbps or > 10Gbps) via ethtool_ops.set_link_ksettings. > > Also fix the function assigned to

Re: [PATCH v2 net-next 2/4] net: add skeleton of bpfilter kernel module

On Wed, May 02, 2018 at 09:36:02PM -0700, Alexei Starovoitov wrote: > bpfilter.ko consists of bpfilter_kern.c (normal kernel module code) > and user mode helper code that is embedded into bpfilter.ko > > The steps to build bpfilter.ko are the following: > - main.c is compiled by HOSTCC into the

Re: [PATCH v2 net-next 1/4] umh: introduce fork_usermode_blob() helper

On Fri, May 04, 2018 at 06:37:11PM -0700, Alexei Starovoitov wrote: > On Fri, May 04, 2018 at 07:56:43PM +, Luis R. Rodriguez wrote: > > What a mighty short list of reviewers. Adding some more. My review below. > > I'd appreciate a Cc on future versions of these patches. > > sure. > > > On

Re: [PATCH v2 net-next 2/4] net: add skeleton of bpfilter kernel module

From: Harald Welte Date: Mon, 7 May 2018 17:24:35 +0200 > But if the ruleset loads but behaves different than before (because e.g. > it's executed from a completely different place in the stack), that's > IMHO an absolute no-go that must be avoided at all cost. That's not

Re: [PATCH v2 net-next 2/4] net: add skeleton of bpfilter kernel module

Hi Alexei + netdev list, On Wed, May 02, 2018 at 09:36:02PM -0700, Alexei Starovoitov wrote: > Later bpfilter_process_sockopt() will be called from bpfilter hooks > in get/setsockopt() to pass iptable commands into umh via bpfilter.ko This is a part I'm quite heavily opposed to - at least at

Re: [PATCH v2 net-next] net: stmmac: Add support for U32 TC filter using Flexible RX Parser

Hi Jakub, David, On 05-05-2018 02:33, Jakub Kicinski wrote: > On Fri, 4 May 2018 10:01:38 +0100, Jose Abreu wrote: >> This adds support for U32 filter by using an HW only feature called >> Flexible RX Parser. This allow us to match any given packet field with a >> pattern and accept/reject or

Re: [PATCH v2 net-next 1/4] umh: introduce fork_usermode_blob() helper

On Sat, May 05, 2018 at 12:48:24AM -0400, Jann Horn wrote: > On Thu, May 3, 2018 at 12:36 AM, Alexei Starovoitov wrote: > > Introduce helper: > > int fork_usermode_blob(void *data, size_t len, struct umh_info *info); > > struct umh_info { > >struct file *pipe_to_umh; > >

Re: [PATCH v2 net-next 1/4] umh: introduce fork_usermode_blob() helper

On Thu, May 3, 2018 at 12:36 AM, Alexei Starovoitov wrote: > Introduce helper: > int fork_usermode_blob(void *data, size_t len, struct umh_info *info); > struct umh_info { >struct file *pipe_to_umh; >struct file *pipe_from_umh; >pid_t pid; > }; > > that

Re: [PATCH v2 net-next 1/4] umh: introduce fork_usermode_blob() helper

On Fri, May 04, 2018 at 07:56:43PM +, Luis R. Rodriguez wrote: > What a mighty short list of reviewers. Adding some more. My review below. > I'd appreciate a Cc on future versions of these patches. sure. > On Wed, May 02, 2018 at 09:36:01PM -0700, Alexei Starovoitov wrote: > > Introduce

Re: [PATCH v2 net-next] net: stmmac: Add support for U32 TC filter using Flexible RX Parser

On Fri, 4 May 2018 10:01:38 +0100, Jose Abreu wrote: > This adds support for U32 filter by using an HW only feature called > Flexible RX Parser. This allow us to match any given packet field with a > pattern and accept/reject or even route the packet to a specific DMA > channel. > > Right now we

Re: [PATCH v2 net-next 2/4] net: add skeleton of bpfilter kernel module

On Thu, May 03, 2018 at 03:23:55PM +0100, Edward Cree wrote: > On 03/05/18 05:36, Alexei Starovoitov wrote: > > bpfilter.ko consists of bpfilter_kern.c (normal kernel module code) > > and user mode helper code that is embedded into bpfilter.ko > > > > The steps to build bpfilter.ko are the

Re: [PATCH v2 net-next 1/4] umh: introduce fork_usermode_blob() helper

What a mighty short list of reviewers. Adding some more. My review below. I'd appreciate a Cc on future versions of these patches. On Wed, May 02, 2018 at 09:36:01PM -0700, Alexei Starovoitov wrote: > Introduce helper: > int fork_usermode_blob(void *data, size_t len, struct umh_info *info); >

[PATCH V2 net-next] liquidio: support use of ethtool to set link speed of CN23XX-225 cards

From: Weilin Chang Support setting the link speed of CN23XX-225 cards (which can do 25Gbps or 10Gbps) via ethtool_ops.set_link_ksettings. Also fix the function assigned to ethtool_ops.get_link_ksettings to use the new link_ksettings api completely (instead of partially

Re: [PATCH v2 net-next] net: dsa: mv88e6xxx: 88E6141/6341 SERDES support

From: Marek Behún Date: Thu, 3 May 2018 16:27:23 +0200 > The 88E6141/6341 switches (also known as Topaz) have 1 SGMII lane, > which can be configured the same way as the SERDES lane on 88E6390. > > Signed-off-by: Marek Behun This patch doesn't apply

Re: [PATCH v2 net-next] microchip_t1: Add driver for Microchip LAN87XX T1 PHYs

From: Nisar Sayed Date: Wed, 2 May 2018 21:09:17 +0530 > Add driver for Microchip LAN87XX T1 PHYs > > This patch support driver for Microchp T1 PHYs. > There will be followup patches to this driver to support T1 PHY > features such as cable diagnostics, signal quality

[PATCH v2 net-next] net: stmmac: Add support for U32 TC filter using Flexible RX Parser

This adds support for U32 filter by using an HW only feature called Flexible RX Parser. This allow us to match any given packet field with a pattern and accept/reject or even route the packet to a specific DMA channel. Right now we only support acception or rejection of frame and we only support

[PATCH v2 net-next] net: dsa: mv88e6xxx: 88E6141/6341 SERDES support

The 88E6141/6341 switches (also known as Topaz) have 1 SGMII lane, which can be configured the same way as the SERDES lane on 88E6390. Signed-off-by: Marek Behun --- drivers/net/dsa/mv88e6xxx/chip.c | 2 ++ drivers/net/dsa/mv88e6xxx/serdes.c | 20

Re: [PATCH v2 net-next 2/4] net: add skeleton of bpfilter kernel module

On 03/05/18 05:36, Alexei Starovoitov wrote: > bpfilter.ko consists of bpfilter_kern.c (normal kernel module code) > and user mode helper code that is embedded into bpfilter.ko > > The steps to build bpfilter.ko are the following: > - main.c is compiled by HOSTCC into the bpfilter_umh elf

[PATCH v2 net-next 0/4] bpfilter

Hi All, v1->v2: this patch set is almost a full rewrite of the earlier umh modules approach The v1 of patches and follow up discussion was covered by LWN: https://lwn.net/Articles/749108/ I believe the v2 addresses all issues brought up by Andy and others. Mainly there are zero changes to

[PATCH v2 net-next 1/4] umh: introduce fork_usermode_blob() helper

Introduce helper: int fork_usermode_blob(void *data, size_t len, struct umh_info *info); struct umh_info { struct file *pipe_to_umh; struct file *pipe_from_umh; pid_t pid; }; that GPLed kernel modules (signed or unsigned) can use it to execute part of its own data as

[PATCH v2 net-next 2/4] net: add skeleton of bpfilter kernel module

bpfilter.ko consists of bpfilter_kern.c (normal kernel module code) and user mode helper code that is embedded into bpfilter.ko The steps to build bpfilter.ko are the following: - main.c is compiled by HOSTCC into the bpfilter_umh elf executable file - with quite a bit of objcopy and Makefile

Re: [PATCH V2 net-next 0/6] virtio-net: Add SCTP checksum offload support

On Tue, May 01, 2018 at 10:07:33PM -0400, Vladislav Yasevich wrote: > Now that we have SCTP offload capabilities in the kernel, we can add > them to virtio as well. First step is SCTP checksum. SCTP-wise, LGTM: Acked-by: Marcelo Ricardo Leitner

Re: [PATCH V2 net-next 4/6] tun: Add support for SCTP checksum offload

On 05/02/2018 10:56 AM, Marcelo Ricardo Leitner wrote: > On Wed, May 02, 2018 at 11:53:47AM -0300, Marcelo Ricardo Leitner wrote: >> On Tue, May 01, 2018 at 10:07:37PM -0400, Vladislav Yasevich wrote: >>> Adds a new tun offload flag to allow for SCTP checksum offload. >>> The flag has to be set by

Re: [PATCH V2 net-next 4/6] tun: Add support for SCTP checksum offload

On Wed, May 02, 2018 at 11:53:47AM -0300, Marcelo Ricardo Leitner wrote: > On Tue, May 01, 2018 at 10:07:37PM -0400, Vladislav Yasevich wrote: > > Adds a new tun offload flag to allow for SCTP checksum offload. > > The flag has to be set by the user and defaults to "no offload". > > I'm confused

Re: [PATCH V2 net-next 4/6] tun: Add support for SCTP checksum offload

On Tue, May 01, 2018 at 10:07:37PM -0400, Vladislav Yasevich wrote: > Adds a new tun offload flag to allow for SCTP checksum offload. > The flag has to be set by the user and defaults to "no offload". I'm confused here: > +++ b/drivers/net/tun.c > @@ -216,7 +216,7 @@ struct tun_struct { >

Re: [PATCH V2 net-next 2/6] sctp: Handle sctp packets with CHECKSUM_PARTIAL

On Tue, May 01, 2018 at 10:07:35PM -0400, Vladislav Yasevich wrote: > With SCTP checksum offload available in virtio, it is now > possible for virtio to receive a sctp packet with CHECKSUM_PARTIAL > set (guest-to-guest traffic). SCTP doesn't really have a > partial checksum like TCP does, because

Re: [PATCH V2 net-next 1/6] virtio: Add support for SCTP checksum offloading

On Wed, May 02, 2018 at 05:21:38PM +0300, Michael S. Tsirkin wrote: > On Wed, May 02, 2018 at 11:14:13AM -0300, Marcelo Ricardo Leitner wrote: > > On Wed, May 02, 2018 at 06:16:45AM +0300, Michael S. Tsirkin wrote: > > > On Tue, May 01, 2018 at 10:07:34PM -0400, Vladislav Yasevich wrote: > > > >

Re: [PATCH V2 net-next 5/6] macvlan/macvtap: Add support for SCTP checksum offload.

On 05/02/2018 10:17 AM, Michael S. Tsirkin wrote: > On Wed, May 02, 2018 at 10:00:14AM -0400, Vlad Yasevich wrote: >> On 05/02/2018 09:46 AM, Michael S. Tsirkin wrote: >>> On Wed, May 02, 2018 at 09:27:00AM -0400, Vlad Yasevich wrote: On 05/01/2018 11:24 PM, Michael S. Tsirkin wrote: > On

Re: [PATCH V2 net-next 1/6] virtio: Add support for SCTP checksum offloading

On Wed, May 02, 2018 at 11:14:13AM -0300, Marcelo Ricardo Leitner wrote: > On Wed, May 02, 2018 at 06:16:45AM +0300, Michael S. Tsirkin wrote: > > On Tue, May 01, 2018 at 10:07:34PM -0400, Vladislav Yasevich wrote: > > > To support SCTP checksum offloading, we need to add a new feature > > > to

Re: [PATCH V2 net-next 5/6] macvlan/macvtap: Add support for SCTP checksum offload.

On Wed, May 02, 2018 at 10:00:14AM -0400, Vlad Yasevich wrote: > On 05/02/2018 09:46 AM, Michael S. Tsirkin wrote: > > On Wed, May 02, 2018 at 09:27:00AM -0400, Vlad Yasevich wrote: > >> On 05/01/2018 11:24 PM, Michael S. Tsirkin wrote: > >>> On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav

Re: [PATCH V2 net-next 1/6] virtio: Add support for SCTP checksum offloading

On Wed, May 02, 2018 at 06:16:45AM +0300, Michael S. Tsirkin wrote: > On Tue, May 01, 2018 at 10:07:34PM -0400, Vladislav Yasevich wrote: > > To support SCTP checksum offloading, we need to add a new feature > > to virtio_net, so we can negotiate support between the hypervisor > > and the guest. >

Re: [PATCH V2 net-next 5/6] macvlan/macvtap: Add support for SCTP checksum offload.

On 05/02/2018 09:46 AM, Michael S. Tsirkin wrote: > On Wed, May 02, 2018 at 09:27:00AM -0400, Vlad Yasevich wrote: >> On 05/01/2018 11:24 PM, Michael S. Tsirkin wrote: >>> On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: Since we now have support for software CRC32c

Re: [PATCH V2 net-next 5/6] macvlan/macvtap: Add support for SCTP checksum offload.

On Wed, May 02, 2018 at 09:27:00AM -0400, Vlad Yasevich wrote: > On 05/01/2018 11:24 PM, Michael S. Tsirkin wrote: > > On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: > >> Since we now have support for software CRC32c offload, turn it on > >> for macvlan and macvtap devices so

Re: [PATCH V2 net-next 5/6] macvlan/macvtap: Add support for SCTP checksum offload.

On 05/01/2018 11:24 PM, Michael S. Tsirkin wrote: > On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: >> Since we now have support for software CRC32c offload, turn it on >> for macvlan and macvtap devices so that guests can take advantage >> of offload SCTP checksums to the host

[PATCH v2 net-next] microchip_t1: Add driver for Microchip LAN87XX T1 PHYs

Add driver for Microchip LAN87XX T1 PHYs This patch support driver for Microchp T1 PHYs. There will be followup patches to this driver to support T1 PHY features such as cable diagnostics, signal quality indicator(SQI), sleep and wakeup (TC10) support. Signed-off-by: Nisar Sayed

Re: [PATCH V2 net-next 6/6] ipvlan: Add support for SCTP checksum offload

On Tue, 2018-05-01 at 22:07 -0400, Vladislav Yasevich wrote: > Since ipvlan is a software device, we can turn on SCTP checksum > offload and let the checksum be computed at the lower layer. > > Signed-off-by: Vladislav Yasevich > --- > drivers/net/ipvlan/ipvlan_main.c | 3

Re: [PATCH V2 net-next 5/6] macvlan/macvtap: Add support for SCTP checksum offload.

On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: > Since we now have support for software CRC32c offload, turn it on > for macvlan and macvtap devices so that guests can take advantage > of offload SCTP checksums to the host or host hardware. > > Signed-off-by: Vladislav

Re: [PATCH V2 net-next 1/6] virtio: Add support for SCTP checksum offloading

On Tue, May 01, 2018 at 10:07:34PM -0400, Vladislav Yasevich wrote: > To support SCTP checksum offloading, we need to add a new feature > to virtio_net, so we can negotiate support between the hypervisor > and the guest. > The HOST feature bit signifies offloading support for transmit and >

[PATCH V2 net-next 5/6] macvlan/macvtap: Add support for SCTP checksum offload.

Since we now have support for software CRC32c offload, turn it on for macvlan and macvtap devices so that guests can take advantage of offload SCTP checksums to the host or host hardware. Signed-off-by: Vladislav Yasevich --- drivers/net/macvlan.c | 5 +++--

[PATCH V2 net-next 3/6] sctp: Build sctp offload support into the base kernel

With the SCTP checksum offload support added to virtio, it is now possible to get into a situation where SCTP not present in the kernel, but the feature is negotiated. Handle this just like we do IPv6 and other modular offloads. Move the sctp offload out of the sctp module and into the base

[PATCH V2 net-next 1/6] virtio: Add support for SCTP checksum offloading

To support SCTP checksum offloading, we need to add a new feature to virtio_net, so we can negotiate support between the hypervisor and the guest. The HOST feature bit signifies offloading support for transmit and enables device offload features. The GUEST feature bit signifies offloading support

[PATCH V2 net-next 4/6] tun: Add support for SCTP checksum offload

Adds a new tun offload flag to allow for SCTP checksum offload. The flag has to be set by the user and defaults to "no offload". Add SCTP checksum support to the supported tun features. Signed-off-by: Vladislav Yasevich --- drivers/net/tun.c | 7 ++-

[PATCH V2 net-next 0/6] virtio-net: Add SCTP checksum offload support

Now that we have SCTP offload capabilities in the kernel, we can add them to virtio as well. First step is SCTP checksum. We need a new freature in virtio to negotiate this support since SCTP is excluded with the stardard checksum and requires a little bit extra. This series proposes

[PATCH V2 net-next 2/6] sctp: Handle sctp packets with CHECKSUM_PARTIAL

With SCTP checksum offload available in virtio, it is now possible for virtio to receive a sctp packet with CHECKSUM_PARTIAL set (guest-to-guest traffic). SCTP doesn't really have a partial checksum like TCP does, because CRC32c can't do partial additive checksumming. It's all or nothing. So an

[PATCH V2 net-next 6/6] ipvlan: Add support for SCTP checksum offload

Since ipvlan is a software device, we can turn on SCTP checksum offload and let the checksum be computed at the lower layer. Signed-off-by: Vladislav Yasevich --- drivers/net/ipvlan/ipvlan_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

<    1   2   3   4   5   6   7   8   9   10   >