From: Colin King
Date: Tue, 20 Sep 2016 15:48:45 +0100
> From: Colin Ian King
>
> Change predecrement compare to post decrement compare to avoid an
> unsigned integer wrap-around comparison when decrementing idx in
> the while loop.
>
> For
From: Tariq Toukan
Date: Tue, 20 Sep 2016 14:55:31 +0300
> From: Kamal Heib
>
> This patch cleans devlink resources by calling devlink_port_unregister()
> to avoid the following issues:
>
> - Kernel panic when triggering reset flow.
> - Memory leak
From: Rahul Lakkireddy
Date: Tue, 20 Sep 2016 17:13:05 +0530
> This series of patches add support to offload TC u32 filters onto
> Chelsio NICs.
>
> Patch 1 moves current common filter code to separate files
> in order to provide a common api for performing packet
On 9/22/16 2:24 AM, Marcelo wrote:
On Thu, Sep 22, 2016 at 12:18:46AM +0800, hejianet wrote:
Hi Marcelo
sorry for the late, just came back from a vacation.
Hi, no problem. Hope your batteries are recharged now :-)
On 9/14/16 7:55 PM, Marcelo wrote:
Hi Jia,
On Wed, Sep 14, 2016 at
From: Shmulik Ladkani
Date: Tue, 20 Sep 2016 12:48:36 +0300
> In 93515d53b1
> "net: move vlan pop/push functions into common code"
> skb_vlan_pop was moved from its private location in openvswitch to
> skbuff common code.
>
> In case skb has non hw-accel
From: Shmulik Ladkani
Date: Tue, 20 Sep 2016 12:48:37 +0300
> Fix 'skb_vlan_pop' to use eth_type_vlan instead of directly comparing
> skb->protocol to ETH_P_8021Q or ETH_P_8021AD.
>
> Signed-off-by: Shmulik Ladkani
Applied.
From: Shmulik Ladkani
Date: Mon, 19 Sep 2016 19:11:08 +0300
> TCA_VLAN_ACT_MODIFY allows one to change an existing tag.
>
> It accepts same attributes as TCA_VLAN_ACT_PUSH (protocol, id,
> priority).
> If packet is vlan tagged, then the tag gets overwritten according
From: Jann Horn
Date: Sun, 18 Sep 2016 22:58:20 +0200
> There were two net sysctls that could be written from unprivileged net
> namespaces, but weren't actually namespaced.
>
> To fix the existing issues and prevent stuff this from happening again in
> the future, explicitly
From: Jann Horn
Date: Sun, 18 Sep 2016 22:58:20 +0200
> There were two net sysctls that could be written from unprivileged net
> namespaces, but weren't actually namespaced.
>
> To fix the existing issues and prevent stuff this from happening again in
> the future, explicitly
Hi David,
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/David-Howells/rxrpc-Preparation-for-slow-start-algorithm/20160922-085242
config: arm-omap2plus_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
On Thu, 2016-09-22 at 10:22 +0800, f...@ikuai8.com wrote:
> From: Gao Feng
>
> It is valid that the TCP RST packet which does not set ack flag, and bytes
> of ack number are zero. But current seqadj codes would adjust the "0" ack
> to invalid ack number. Actually seqadj need to
On Wed, Sep 21, 2016 at 01:53:10PM +0200, Jiri Pirko wrote:
> From: Jiri Pirko
>
> These helpers are to be used in case someone offloads the FIB entry. The
> result is that if the entry is offloaded to at least one device, the
> offload flag is set.
>
> Signed-off-by: Jiri
On Wed, Sep 21, 2016 at 01:53:09PM +0200, Jiri Pirko wrote:
> From: Jiri Pirko
>
> This allows to pass information about added/deleted FIB entries/rules to
> whoever is interested. This is done in a very similar way as devinet
> notifies address additions/removals.
>
>
Hi David,
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/David-Howells/rxrpc-Preparation-for-slow-start-algorithm/20160922-085242
config: i386-randconfig-h0-09220655 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
Hi David,
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/David-Howells/rxrpc-Preparation-for-slow-start-algorithm/20160922-085242
config: arm-omap2plus_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
The previous patch to ensure that the original iif was used when
checking for forwarding also meant that this same interface was used to
determine whether multicast packets should be received or not. This was
incorrect, and would cause multicast packets to be dropped.
The fix here is to use
Le 21/09/2016 à 19:33, sean.w...@mediatek.com a écrit :
> From: Sean Wang
>
> By default, GMAC0 is connected to built-in switch called
> MT7530 through the proprietary interface called Turbo RGMII
> (TRGMII). TRGMII also supports well for RGMII as generic external
> PHY
From: Sean Wang
Add the dts property for the capability if TRGMII supported on GAMC0
Signed-off-by: Sean Wang
---
Documentation/devicetree/bindings/net/mediatek-net.txt | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
From: Sean Wang
adds PHY-mode "trgmii" as an extension for the operation
mode of the PHY interface for PHY_INTERFACE_MODE_TRGMII.
and adds a variable trgmii inside mtk_mac as the indication
to make the difference between the MAC connected to internal
switch or connected
From: Sean Wang
Changing dynamically source clock, TX/RX delay and interface mode
used by TRGMII hardware module inside PHY capability polling routine
for adapting to the various speed of RGMII used by external PHY for
GMAC0.
Signed-off-by: Sean Wang
From: Sean Wang
By default, GMAC0 is connected to built-in switch called
MT7530 through the proprietary interface called Turbo RGMII
(TRGMII). TRGMII also supports well for RGMII as generic external
PHY uses but requires some slight changes to the setup of TRGMII
and
From: Gao Feng
It is valid that the TCP RST packet which does not set ack flag, and bytes
of ack number are zero. But current seqadj codes would adjust the "0" ack
to invalid ack number. Actually seqadj need to check the ack flag before
adjust it for these RST packets.
The
On Wed, 2016-09-21 at 16:16 -0700, Yuchung Cheng wrote:
> This patch fixes these under-accounting SNMP rtx stats
> LINUX_MIB_TCPFORWARDRETRANS
> LINUX_MIB_TCPFASTRETRANS
> LINUX_MIB_TCPSLOWSTARTRETRANS
> when retransmitting TSO packets
>
> Fixes: 10d3be569243 ("tcp-tso: do not split TSO packets
From: Tariq Toukan
Date: Tue, 20 Sep 2016 14:39:38 +0300
> This patchset contains some cleanups and improvements from the team
> to the mlx4 Eth and core drivers.
>
> Series generated against net-next commit:
> 5a7aa362 'net sched: stylistic cleanups'
Series applied,
From: Kalle Valo
Date: Tue, 20 Sep 2016 13:20:46 +0300
> last pull request for 4.8, unless something really drastic comes up. And
> a small one even, just a small fix to iwlwifi to avoid a firmware crash.
>
> Please let me know if there are any problems.
Pulled, thanks.
Hi David,
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/David-Howells/rxrpc-Preparation-for-slow-start-algorithm/20160922-085242
config: i386-randconfig-x009-201638 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
We don't want to send a PING ACK for every new incoming call as that just
adds to the network traffic. Instead, we send a PING ACK to the first
three that we receive and then once per second thereafter.
This could probably be made adjustable in future.
Signed-off-by: David Howells
In addition to sending a PING ACK to gain RTT data, we can set the
RXRPC_REQUEST_ACK flag on a DATA packet and get a REQUESTED-ACK ACK. The
ACK packet contains the serial number of the packet it is in response to,
so we can look through the Tx buffer for a matching DATA packet.
This requires
Add a ktime_sub_ms() to go with ktime_add_ms() and co. for use in AF_RXRPC
RTT determination.
Signed-off-by: David Howells
---
include/linux/ktime.h |5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/ktime.h b/include/linux/ktime.h
index
Don't store the rxrpc protocol header in sk_buffs on the transmit queue,
but rather generate it on the fly and pass it to kernel_sendmsg() as a
separate iov. This reduces the amount of storage required.
Note that the security header is still stored in the sk_buff as it may get
encrypted along
Expedite the transmission of a response to a PING ACK by sending it from
sendmsg if one is pending. We're most likely to see a PING ACK during the
client call Tx phase as the other side may use it to determine a number of
parameters, such as the client's receive window size, the RTT and whether
Reduce the number of ACK-Requests we set on DATA packets that we're sending
to reduce network traffic. We set the flag on odd-numbered DATA packets to
start off the RTT cache until we have at least three entries in it and then
probe once per second thereafter to keep it topped up.
This could be
Here are some patches that prepare for improvements in ACK generation and
for the implementation of the slow-start part of the protocol:
(1) Stop storing the protocol header in the Tx socket buffers, but rather
generate it on the fly. This potentially saves a little space and
makes
Send a PING ACK packet to the peer when we get a new incoming call from a
peer we don't have a record for. The PING RESPONSE ACK packet will tell us
the following about the peer:
(1) its receive window size
(2) its MTU sizes
(3) its support for jumbo DATA packets
(4) if it supports slow
Add a Tx-phase annotation for packet buffers to indicate that a buffer has
already been retransmitted. This will be used by future congestion
management. Re-retransmissions of a packet don't affect the congestion
window managment in the same way as initial retransmissions.
Signed-off-by: David
Add a function to track the average RTT for a peer. Sources of RTT data
will be added in subsequent patches.
The RTT data will be useful in the future for determining resend timeouts
and for handling the slow-start part of the Rx protocol.
Also add a pair of tracepoints, one to log
On Tue, Sep 20, 2016 at 2:08 AM, Jesper Dangaard Brouer
wrote:
> Hi all,
>
> As promised, I've started documenting the XDP eXpress Data Path):
>
> [1]
> https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/index.html
>
> IMHO the documentation have reached a stage
From: Jakub Kicinski
Date: Wed, 21 Sep 2016 11:43:52 +0100
> In the last year a lot of progress have been made on offloading
> simpler TC classifiers. There is also growing interest in using
> BPF for generic high-speed packet processing in the kernel.
> It seems
On Mon, 19 Sep 2016 17:03:14 -0700
Alexei Starovoitov wrote:
> Signed-off-by: Alexei Starovoitov
Applied, please send update to man page as well.
On Tue, 20 Sep 2016 02:09:02 -0700
Liping Zhang wrote:
> From: Liping Zhang
>
> In ip monitor, netns_map_init will check getnsid is supported or not.
> But when /proc/self/ns/net does not exist, we just print out error
> messages and exit. So
On Wed, 2016-09-21 at 19:23 +0200, Paolo Abeni wrote:
> Avoid usage of common memory accounting functions, since
> the logic is pretty much different.
>
> To account for forward allocation, a couple of new atomic_t
> members are added to udp_sock: 'mem_alloced' and 'mem_freed'.
> The current
On Tue, 20 Sep 2016 22:43:44 -0400
Neal Cardwell wrote:
> Dump useful TCP BBR state information from a struct tcp_bbr_info that
> was grabbed using the inet_diag API.
>
> We tolerate info that is shorter or longer than expected, in case the
> kernel is older or newer than
This patch fixes these under-accounting SNMP rtx stats
LINUX_MIB_TCPFORWARDRETRANS
LINUX_MIB_TCPFASTRETRANS
LINUX_MIB_TCPSLOWSTARTRETRANS
when retransmitting TSO packets
Fixes: 10d3be569243 ("tcp-tso: do not split TSO packets at retransmit time")
Signed-off-by: Yuchung Cheng
Since the TFO socket is accepted right off SYN-data, the socket
owner can call getsockopt(TCP_INFO) to collect ongoing SYN-ACK
retransmission or timeout stats (i.e., tcpi_total_retrans,
tcpi_retransmits). Currently those stats are only updated
upon handshake completes. This patch fixes it.
The RXDES and TXDES registers bits in the ftgmac100 indicates EDO{R,T}R
at bit position 15 for the Faraday Tech IP. However, the version of this
IP present in the Aspeed SoCs has these bits at position 30 in the
registers.
It appers that ast2400 SoCs support both positions, with the 15th bit
The PHYSTS_CHG (the ftgmac100's PHY IRQ) is telling the system to go
look at the PHY registers for a link status change.
The interrupt was causing issues on Aspeed SoC where some board designs
had an active high configuration, some active low, and in some cases
repurposed for other functions.
From: Andrew Jeffery
The ftgmac100 hardware revision in e.g. the Aspeed AST2500 no longer
reserves all bits in RXDES#2 but instead uses the bottom 16 bits to
store MAC frame metadata. Avoid corruption by shifting struct page
pointers out to their own member in struct ftgmac100.
Please ignore this one.
On Thu, Sep 22, 2016 at 8:33 AM, Joel Stanley wrote:
> Hello Dave,
>
> This series adds support to the ftgmac100 driver for the Aspeed ast2400 and
> ast2500 SoCs. In particular, they ensure the driver works correctly on the
> ast2500 where the MAC block
From: Gavin Shan
There is stale interrupt (PHYSTS_CHG in ISR, bit#6 in 0x0) from
the bootloader (uboot) when enabling the MAC. The stale interrupts
aren't part of kernel and should be cleared.
This clears the stale interrupts in ISR (0x0) when enabling the MAC.
The Aspeed SoCs have a new MDIO interface as an option in the G4 and G5
SoCs. The old one is still available, so select it in order to remain
compatible with the ftgmac100 driver.
Signed-off-by: Joel Stanley
---
drivers/net/ethernet/faraday/ftgmac100.c | 9 +
Hello Dave,
This series adds support to the ftgmac100 driver for the Aspeed ast2400 and
ast2500 SoCs. In particular, they ensure the driver works correctly on the
ast2500 where the MAC block has seen some changes in register layout.
They have been tested on ast2400 and ast2500 systems with the
From: Andrew Jeffery
These bits are #defined at a fixed location. In order to support future
hardware that has chosen to move these bits around move the bits into a
member of the struct ftgmac100.
Signed-off-by: Andrew Jeffery
Signed-off-by: Joel Stanley
Hello Dave,
This series adds support to the ftgmac100 driver for the Aspeed ast2400 and
ast2500 SoCs. In particular, they ensure the driver works correctly on the
ast2500 where the MAC block has seen some changes in register layout.
They have been tested on ast2400 and ast2500 systems with the
On Wed, 2016-09-21 at 22:21 +0300, Or Gerlitz wrote:
> On Wed, Sep 21, 2016 at 7:59 PM, Samudrala, Sridhar
> wrote:
> > On 9/21/2016 12:04 AM, Or Gerlitz wrote:
>
>
> >> so what happens after this patchset is applied and before the future
> work is
> >> submitted?
Take into account all of the tunnel encapsulation headers when setting
up the MTU on the L2TP logical interface device. Otherwise, packets
created by the applications on top of the L2TP layer are larger
than they ought to be, relative to the underlay MTU, leading to
needless fragmentation once
On Wed, 21 Sep 2016 08:08:34 -0700 Tom Herbert wrote:
> On Wed, Sep 21, 2016 at 7:48 AM, Thomas Graf wrote:
> > On 09/21/16 at 07:19am, Tom Herbert wrote:
> >> certain design that because of constraints on one kernel interface. As
> >> a kernel developer
+static int qedr_set_page(struct ib_mr *ibmr, u64 addr)
+{
+ struct qedr_mr *mr = get_qedr_mr(ibmr);
+ struct qedr_pbl *pbl_table;
+ struct regpair *pbe;
+ u32 pbes_in_page;
+
+ if (unlikely(mr->npages == mr->info.pbl_info.num_pbes)) {
+
On Wed, Sep 21, 2016 at 7:59 PM, Samudrala, Sridhar
wrote:
> On 9/21/2016 12:04 AM, Or Gerlitz wrote:
>> so what happens after this patchset is applied and before the future work is
>> submitted? RX/TX slow path through the VFPRs isn't supported and what
>> about
On 09/21/16 at 11:50am, Tom Herbert wrote:
> 50 lines in one driver is not a big deal, 50 lines in a hundred
> drivers is! I learned this lesson in BQL which was well abstracted out
> to be minimally invasive but we still saw many issues because of the
> pecularities of different drivers.
You
On Wed, 21 Sep 2016 11:50:06 -0700, Tom Herbert wrote:
> On Wed, Sep 21, 2016 at 11:45 AM, Jakub Kicinski wrote:
> > On Wed, 21 Sep 2016 10:39:40 -0700, Tom Herbert wrote:
> >> On Wed, Sep 21, 2016 at 10:26 AM, Jakub Kicinski wrote:
> >> > On Tue, 20 Sep 2016
On Wed, Sep 21, 2016 at 11:45 AM, Jakub Kicinski wrote:
> On Wed, 21 Sep 2016 10:39:40 -0700, Tom Herbert wrote:
>> On Wed, Sep 21, 2016 at 10:26 AM, Jakub Kicinski wrote:
>> > On Tue, 20 Sep 2016 17:01:39 -0700, Alexei Starovoitov wrote:
>> >> > - Reduces the
On 09/21/16 at 05:45pm, Pablo Neira Ayuso wrote:
> On Tue, Sep 20, 2016 at 06:43:35PM +0200, Daniel Mack wrote:
> > The point is that from an application's perspective, restricting the
> > ability to bind a port and dropping packets that are being sent is a
> > very different thing. Applications
On Wed, 21 Sep 2016 10:39:40 -0700, Tom Herbert wrote:
> On Wed, Sep 21, 2016 at 10:26 AM, Jakub Kicinski wrote:
> > On Tue, 20 Sep 2016 17:01:39 -0700, Alexei Starovoitov wrote:
> >> > - Reduces the amount of code and complexity needed in drivers to
> >> >manage XDP
>
With TCP MTU probing enabled and offload TX checksumming disabled,
tcp_mtu_probe() calculated the wrong checksum when a fragment being copied
into the probe's SKB had an odd length. This was caused by the direct use
of skb_copy_and_csum_bits() to calculate the checksum, as it pads the
fragment
On Thu, Sep 22, 2016 at 12:18:46AM +0800, hejianet wrote:
> Hi Marcelo
>
> sorry for the late, just came back from a vacation.
Hi, no problem. Hope your batteries are recharged now :-)
>
> On 9/14/16 7:55 PM, Marcelo wrote:
> > Hi Jia,
> >
> > On Wed, Sep 14, 2016 at 01:58:42PM +0800,
Hi Tom,
On Wed, Sep 21, 2016 at 10:16:45AM -0700, Tom Herbert wrote:
> This does seem interesting and indeed the driver datapath looks very
> much like XDP. It would be quite interesting if you could rebase and
> then maybe look at how this can work with XDP that would be helpful.
OK I'll assign
Hi Jesper!
On Wed, Sep 21, 2016 at 06:26:39PM +0200, Jesper Dangaard Brouer wrote:
> I definitely want to study it!
Great, at least I've not put this online for nothing :-)
> You mention XDP. If you didn't notice, I've created some documentation
> on XDP (it is very "live" documentation at
From: Gavin Schenk Sent: Wednesday, September 21, 2016
9:31 PM
> To: Andy Duan
> Cc: netdev@vger.kernel.org; ker...@pengutronix.de; Gavin Schenk
>
> Subject: [PATCH] net: fec: set mac address unconditionally
>
> Fixes:
On Wed, Sep 21, 2016 at 10:26 AM, Jakub Kicinski wrote:
> On Tue, 20 Sep 2016 17:01:39 -0700, Alexei Starovoitov wrote:
>> > - Reduces the amount of code and complexity needed in drivers to
>> >manage XDP
>>
>> hmm:
>> 534 insertions(+), 144 deletions(-)
>> looks like
Hello, I am Saidat, I sent you a message yesterday, Please did you
receive it? Thank you!
On Tue, 20 Sep 2016 17:01:39 -0700, Alexei Starovoitov wrote:
> > - Reduces the amount of code and complexity needed in drivers to
> >manage XDP
>
> hmm:
> 534 insertions(+), 144 deletions(-)
> looks like increase in complexity instead.
and more to come to tie this with HW offloads.
On Wed, 21 Sep 2016 13:55:45 +0200, Thomas Graf wrote:
> > I am looking at using this for ILA router. The problem I am hitting is
> > that not all packets that we need to translate go through the XDP
> > path. Some would go through the kernel path, some through XDP path but
>
> When you say
Basic sock operations that udp code can use with its own
memory accounting schema. No functional change is introduced
in the existing APIs.
Acked-by: Hannes Frederic Sowa
Signed-off-by: Paolo Abeni
---
include/linux/skbuff.h | 2 +-
Avoid usage of common memory accounting functions, since
the logic is pretty much different.
To account for forward allocation, a couple of new atomic_t
members are added to udp_sock: 'mem_alloced' and 'mem_freed'.
The current forward allocation is estimated as 'mem_alloced'
minus 'mem_freed'
Completely avoid default sock memory accounting and replace it
with udp-specific accounting.
Since the new memory accounting model does not require socket
locking, remove the lock on enqueue and free and avoid using the
backlog on enqueue.
Be sure to clean-up rx queue memory on socket
This patch series refactor the udp memory accounting, replacing the
generic implementation with a custom one, in order to remove the needs for
locking the socket on the enqueue and dequeue operations. The socket backlog
usage is dropped, as well.
The first patch factor out core pieces of some
On Wed, Sep 21, 2016 at 4:28 AM, Willy Tarreau wrote:
> Hi,
>
> Over the last 3 years I've been working a bit on high traffic processing
> for various reasons. It started with the wish to capture line-rate GigE
> traffic on very small fanless ARM machines and the framework has
On Wed, Sep 21, 2016 at 09:53:31AM -0700, Eric Dumazet wrote:
> On Wed, 2016-09-21 at 09:14 -0700, Alexei Starovoitov wrote:
>
> >
> > I think it's the opposite. Even on x86 compiler will use byte loads.
>
> Unless you tweaked gcc, it should still use word loads on x86.
> checked that on
Hi Marcelo
sorry for the late, just came back from a vacation.
On 9/14/16 7:55 PM, Marcelo wrote:
Hi Jia,
On Wed, Sep 14, 2016 at 01:58:42PM +0800, hejianet wrote:
Hi Marcelo
On 9/13/16 2:57 AM, Marcelo wrote:
On Fri, Sep 09, 2016 at 02:33:57PM +0800, Jia He wrote:
This is to use the
On 09/21/2016 12:33 AM, Sean Wang wrote:
> Date: Tue, 20 Sep 2016 14:23:24 -0700, Florian Fainelli
> wrote:
>> On 09/20/2016 12:59 AM, sean.w...@mediatek.com wrote:
>>> From: Sean Wang
>>>
>>> adds PHY-mode "trgmii" as an extension for the operation
On 9/21/2016 12:04 AM, Or Gerlitz wrote:
On Wed, Sep 21, 2016 at 8:45 AM, Samudrala, Sridhar
wrote:
On 9/20/2016 9:22 PM, Or Gerlitz wrote:
On Wed, Sep 21, 2016 at 6:43 AM, Jeff Kirsher
wrote:
From: Sridhar Samudrala
On 09/20/2016 08:33 PM, Michael Chan wrote:
> Taking over as maintainer since Gary Zambrano is no longer working
> for Broadcom.
>
> Signed-off-by: Michael Chan
Acked-by: Florian Fainelli
Thanks Michael!
--
Florian
On Wed, 2016-09-21 at 09:14 -0700, Alexei Starovoitov wrote:
>
> I think it's the opposite. Even on x86 compiler will use byte loads.
Unless you tweaked gcc, it should still use word loads on x86.
On 21.09.2016 18:14, Alexei Starovoitov wrote:
> On Wed, Sep 21, 2016 at 12:10:55PM +0200, Hannes Frederic Sowa wrote:
>> On 20.09.2016 20:57, Sowmini Varadhan wrote:
>>> The vxlan header may not be aligned to 4 bytes in
>>> vxlan_build_skb (e.g., for MLD packets). This patch
>>> avoids unaligned
On Wed, 21 Sep 2016 13:28:52 +0200 Willy Tarreau wrote:
> Over the last 3 years I've been working a bit on high traffic processing
> for various reasons. It started with the wish to capture line-rate GigE
> traffic on very small fanless ARM machines and the framework has evolved
>
Without that fix, the following could occur:
- On encode ingress, the total amount of skb_pushes (in lines 751 and
753) was more than specified in cow.
- On machines with hard_header_len > mac_len, the packet format was not
according to the ife specifications, as the place reserved at the
On Wed, Sep 21, 2016 at 12:10:55PM +0200, Hannes Frederic Sowa wrote:
> On 20.09.2016 20:57, Sowmini Varadhan wrote:
> > The vxlan header may not be aligned to 4 bytes in
> > vxlan_build_skb (e.g., for MLD packets). This patch
> > avoids unaligned access traps from vxlan_build_skb
> > (in
This allows the user to dump sockets with a given mark (via
"fwmark = 0x1234/0x1234" or "fwmark = 12345", etc.) , and to
display the socket marks of dumped sockets.
The relevant kernel commits are: d545caca827b ("net: inet: diag:
expose the socket mark to privileged processes.") and
-
Hi Daniel,
On Tue, Sep 20, 2016 at 06:43:35PM +0200, Daniel Mack wrote:
> Hi Pablo,
>
> On 09/20/2016 04:29 PM, Pablo Neira Ayuso wrote:
> > On Mon, Sep 19, 2016 at 10:56:14PM +0200, Daniel Mack wrote:
> > [...]
> >> Why would we artificially limit the use-cases of this implementation if
> >>
On Wed, Sep 21, 2016 at 02:23:46PM +, Amrani, Ram wrote:
> > Ugh, each patch keeps adding to this?
>
> The logic in the patch series is to have each patch contain only
> what is necessary for the specific functionality it adds. This made
> it harder on us to prepare but, IMHO, easier for the
Aaron Conole writes:
> The netfilter hook list never uses the prev pointer, and so can be trimmed to
> be a simple singly-linked list.
>
> In addition to having a more light weight structure for hook traversal,
> struct net becomes 5568 bytes (down from 6400) and struct
On 9/20/16 11:39 PM, Jesper Dangaard Brouer wrote:
We are the early stages of XDP development. Users cannot consider XDP a
stable UAPI yet. I added a big fat warning to the docs here[1].
If you already consider this a stable API, then I will suggest that we
disable XDP or rip the hole thing
The netfilter hook list never uses the prev pointer, and so can be trimmed to
be a simple singly-linked list.
In addition to having a more light weight structure for hook traversal,
struct net becomes 5568 bytes (down from 6400) and struct net_device becomes
2176 bytes (down from 2240).
Date: Wed, 21 Sep 2016 16:17:20 +0200, Andrew Lunn wrote:
>On Wed, Sep 21, 2016 at 02:16:30PM +0800, Sean Wang wrote:
>> Date: Tue, 20 Sep 2016 21:37:58 +0200, Andrew Lunn wrote:
>> >On Tue, Sep 20, 2016 at 03:59:20PM +0800, sean.w...@mediatek.com wrote:
>> >>
On 9/21/16 7:19 AM, Tom Herbert wrote:
#1: Should we allow alternate code to run in XDP other than BPF?
separate nft hook - yes
generic hook - no
since it's one step away from kernel modules abusing this hook.
pass/drop/tx of raw buffer at the driver level is a perfect
interface to bypass
On Wed, Sep 21, 2016 at 08:45:54AM -0300, Marcelo Ricardo Leitner wrote:
> This patchset aims to rename these macros to a non-confusing name, as
> reported by David Laight and David Miller, and to update all remaining
> places to make use of it, which was 1 last remaining spot.
>
> v3:
> - Name
This commit adds an upfront check for sane values to be passed when
registering a netfilter hook. This will be used in a future patch for a
simplified hook list traversal.
Signed-off-by: Aaron Conole
---
net/netfilter/core.c | 5 +
1 file changed, 5 insertions(+)
diff
From: Florian Westphal
This replaces the last uses of NF_HOOK_THRESH().
Followup patch will remove it and rename nf_hook_thresh.
The reason is that inet (non-bridge) netfilter no longer invokes the
hooks from hooks, so we do no longer need the thresh value to skip hooks
with a
From: Florian Westphal
This makes things simpler because we can store the head of the list
in the nf_state structure without worrying about concurrent add/delete
of hook elements from the list.
A future commit will make use of this to implement a simpler
linked-list.
This commit ensures that the rcu read-side lock is held while the
ingress hook is called. This ensures that a call to nf_hook_slow (and
ultimately nf_ingress) will be read protected.
Signed-off-by: Aaron Conole
---
net/core/dev.c | 7 ++-
1 file changed, 6
1 - 100 of 205 matches
Mail list logo