All the callers of ip6_rt_copy_init()/rt6_set_from() hold refcnt
of the "from" fib6_info, so there is no need to hold fib6_metrics
refcnt again, because fib6_metrics refcnt is only released when
fib6_info is gone, that is, they have the same life time, so the
whole fib6_metrics refcnt can be remove
On Thu, Aug 02, 2018 at 11:21:41AM -0400, Willem de Bruijn wrote:
> You have two sockets bound to the same address and port? Is this using
> SO_REUSEPORT?
Yes, this is using SO_REUSEPORT.
My colleague wrote a python reproducer for this here:
https://gist.github.com/povilasb/53f1c802dbc2aca36a0ffa
From: Jakub Kicinski
Date: Thu, 2 Aug 2018 19:30:27 -0700
> commit 38d5d3b3d5db ("bpf: Introduce BPF_ANNOTATE_KV_PAIR")
>
> added to the bpf and net trees what
>
> commit 92b57121ca79 ("bpf: btf: export btf types and name by offset from lib")
>
> has already added to bpf-next/net-next, but in
commit 38d5d3b3d5db ("bpf: Introduce BPF_ANNOTATE_KV_PAIR")
added to the bpf and net trees what
commit 92b57121ca79 ("bpf: btf: export btf types and name by offset from lib")
has already added to bpf-next/net-next, but in slightly different
location. Remove the duplicates (to fix build of libbp
On Sun, Jul 29, 2018 at 11:34:50AM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> IP link was broken due to the changes in IPoIB for the rdma_netdev
> support after commit cd565b4b51e5 ("IB/IPoIB: Support acceleration options
> callbacks").
>
> This patchset restores IPoIB pkey creat
> -Original Message-
> From: Doron Roberts-Kedes [mailto:doro...@fb.com]
> Sent: Friday, August 3, 2018 6:00 AM
> To: David S . Miller
> Cc: Dave Watson ; Vakul Garg
> ; Boris Pismenny ; Aviad
> Yehezkel ; netdev@vger.kernel.org; Doron
> Roberts-Kedes
> Subject: [PATCH net-next] net/tl
decrypt_skb fails if the number of sg elements required to map is
greater than MAX_SKB_FRAGS. As noted by Vakul Garg, nsg must always be
calculated, but skb_cow_data adds unnecessary memcpy's for the zerocopy
case.
The new function skb_nsg calculates the number of scatterlist elements
required to
On Thu, Aug 02, 2018 at 09:50:58AM -0700, Dave Watson wrote:
> On 08/02/18 09:50 PM, Vakul Garg wrote:
> > Function decrypt_skb() made a bad assumption that number of sg entries
> > required for mapping skb to be decrypted would always be less than
> > MAX_SKB_FRAGS. The required count of sg entrie
don't bother with pathological cases, they only waste cycles.
IPv6 requires a minimum MTU of 1280 so we should never see fragments
smaller than this (except last frag).
v3: don't use awkward "-offset + len"
v2: drop IPv4 part, which added same check w. IPV4_MIN_MTU (68).
There were concerns th
On Fri, 3 Aug 2018 02:05:39 +0200
Florian Westphal wrote:
> + if (-skb_network_offset(skb) + skb->len < IPV6_MIN_MTU &&
Is there a reason to write the arithmetic expression in this order?
Why not:
if (skb->len - skb_network_offset(skb) < IPV6_MIN_MTU &&
On Thu, 2 Aug 2018 23:34:37 +
Peter Oskolkov wrote:
> This behavior is required in IPv6, and there is little need
> to tolerate overlapping fragments in IPv4. This change
> simplifies the code and eliminates potential DDoS attack vectors.
>
> Tested: ran ip_defrag selftest (not yet availabl
don't bother with pathological cases, they only waste cycles.
IPv6 requires a minimum MTU of 1280 so we should never see fragments
smaller than this (except last frag).
v2: drop IPv4 part, which added same check w. IPV4_MIN_MTU (68).
There were concerns that there could be even smaller frags
On Thu, 2 Aug 2018 16:33:55 -0700
Eric Dumazet wrote:
> On 08/02/2018 03:54 PM, Stephen Hemminger wrote:
> > On Thu, 2 Aug 2018 22:45:58 +
> > Peter Oskolkov wrote:
> >
> >> diff --git a/include/uapi/linux/snmp.h b/include/uapi/linux/snmp.h
> >> index e5ebc83827ab..da1a144f1a51 100644
>
On 08/02/2018 04:43 PM, Florian Westphal wrote:
> don't bother with pathological cases, they only waste cycles.
> IPv6 requires a minimum MTU of 1280 so we should never see fragments
> smaller than this (except last frag).
>
> For IPv4, in practice, we could probably also adopt a higher limit,
don't bother with pathological cases, they only waste cycles.
IPv6 requires a minimum MTU of 1280 so we should never see fragments
smaller than this (except last frag).
For IPv4, in practice, we could probably also adopt a higher limit,
but for now use ipv4 min mtu (68).
Cc: Peter Oskolkov
Cc: E
Tested: see the next patch is the series.
Suggested-by: Eric Dumazet
Signed-off-by: Peter Oskolkov
Signed-off-by: Eric Dumazet
Cc: Florian Westphal
---
include/linux/skbuff.h | 2 +-
net/core/skbuff.c | 6 +-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/lin
This behavior is required in IPv6, and there is little need
to tolerate overlapping fragments in IPv4. This change
simplifies the code and eliminates potential DDoS attack vectors.
Tested: ran ip_defrag selftest (not yet available uptream).
Suggested-by: David S. Miller
Signed-off-by: Peter Osko
This patchset
* changes IPv4 defrag behavior to match that of IPv6: overlapping
fragments now cause the whole IP datagram to be discarded (suggested
by David Miller): there are no legitimate use cases for overlapping
fragments;
* changes IPv4 defrag queue from a list to a rb tree (sugges
On 08/02/2018 03:54 PM, Stephen Hemminger wrote:
> On Thu, 2 Aug 2018 22:45:58 +
> Peter Oskolkov wrote:
>
>> diff --git a/include/uapi/linux/snmp.h b/include/uapi/linux/snmp.h
>> index e5ebc83827ab..da1a144f1a51 100644
>> --- a/include/uapi/linux/snmp.h
>> +++ b/include/uapi/linux/snmp.h
Similar to TCP OOO RX queue, it makes sense to use rb trees to store
IP fragments, so that OOO fragments are inserted faster.
Tested:
- a follow-up patch contains a rather comprehensive ip defrag
self-test (functional)
- ran neper `udp_stream -c -H -F 100 -l 300 -T 20`:
netstat --statistic
Hi David,
Turns out the VRF bridge Rx issue is triggered by a docker install.
Docker makes the following sysctl changes:
net.bridge.bridge-nf-call-arptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1 <<< exposes the ipv4 VRF Rx issue
when a bridg
On Thu, 2 Aug 2018 22:45:58 +
Peter Oskolkov wrote:
> diff --git a/include/uapi/linux/snmp.h b/include/uapi/linux/snmp.h
> index e5ebc83827ab..da1a144f1a51 100644
> --- a/include/uapi/linux/snmp.h
> +++ b/include/uapi/linux/snmp.h
> @@ -40,6 +40,7 @@ enum
> IPSTATS_MIB_REASMREQDS,
On Thu, 2 Aug 2018 18:07:18 +0300, Eran Ben Elisha wrote:
> On 8/2/2018 4:40 AM, David Miller wrote:
> > From: Jakub Kicinski
> > Date: Wed, 1 Aug 2018 17:00:47 -0700
> >
> >> On Wed, 1 Aug 2018 14:52:45 -0700, Saeed Mahameed wrote:
> >>> - According to the discussion outcome, we are keeping
Similar to TCP OOO RX queue, it makes sense to use rb trees to store
IP fragments, so that OOO fragments are inserted faster.
Tested:
- a follow-up patch contains a rather comprehensive ip defrag
self-test (functional)
- ran neper `udp_stream -c -H -F 100 -l 300 -T 20`:
netstat --statistic
This patchset
* changes IPv4 defrag behavior to match that of IPv6: overlapping
fragments now cause the whole IP datagram to be discarded (suggested
by David Miller): there are no legitimate use cases for overlapping
fragments;
* changes IPv4 defrag queue from a list to a rb tree (sugges
Suggested-by: Eric Dumazet
Signed-off-by: Peter Oskolkov
Signed-off-by: Eric Dumazet
Cc: Florian Westphal
---
include/linux/skbuff.h | 2 +-
net/core/skbuff.c | 6 +-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index f
This behavior is required in IPv6, and there is little need
to tolerate overlapping fragments in IPv4. This change
simplifies the code and eliminates potential DDoS attack vectors.
Suggested-by: David S. Miller
Signed-off-by: Peter Oskolkov
Signed-off-by: Eric Dumazet
Cc: Florian Westphal
---
From: Matthieu Baerts
Date: Thu, 2 Aug 2018 18:14:33 +0200
> This refactoring work has been started by David Howells in cdfbabfb2f0c
> (net: Work around lockdep limitation in sockets that use sockets) but
> the exact same day in 581319c58600 (net/socket: use per af lockdep
> classes for sk queue
From: Denis Bolotin
Date: Thu, 2 Aug 2018 11:12:49 +0300
> +int qed_dcbx_get_priority_tc(struct qed_hwfn *p_hwfn, u8 pri, u8 *p_tc)
Since the value range of the tc priority is 8-bit unsigned, you don't
need to return it by reference.
Simply return the value straight to the caller as an integer.
David Miller writes:
> From: Jakub Kicinski
> Date: Thu, 2 Aug 2018 10:11:12 -0700
>
>> On Thu, 02 Aug 2018 11:29:12 +0300, Petr Machata wrote:
>>> Could you please clarify your remark?
>>
>> Oh, I think David meant the patches I was objecting to a while ago,
>> which were doing buffer configur
Hello,
I hope you're doing well!
I am following up with you on the below since I have not heard back from
you. Please let me know if you would like to get more information on the
same.
Looking forward to hearing from you.
Best Wishes,
Lisa
From: Lisa Parker [mailto:lisa.par...@pre-conf
From: Jakub Kicinski
Date: Thu, 2 Aug 2018 10:11:12 -0700
> On Thu, 02 Aug 2018 11:29:12 +0300, Petr Machata wrote:
>> Could you please clarify your remark?
>
> Oh, I think David meant the patches I was objecting to a while ago,
> which were doing buffer configuration via the DCB API.
Exactly.
From: Ganesh Goudar
Date: Thu, 2 Aug 2018 15:34:52 +0530
> Signed-off-by: Ganesh Goudar
Applied.
> -Original Message-
> From: Dave Watson [mailto:davejwat...@fb.com]
> Sent: Thursday, August 2, 2018 10:47 PM
> To: Vakul Garg
> Cc: netdev@vger.kernel.org; bor...@mellanox.com;
> avia...@mellanox.com; da...@davemloft.net
> Subject: Re: [PATCH net-next] net/tls: Mark the end in scatter
> -Original Message-
> From: Dave Watson [mailto:davejwat...@fb.com]
> Sent: Thursday, August 2, 2018 2:17 AM
> To: Vakul Garg
> Cc: netdev@vger.kernel.org; Peter Doliwa ; Boris
> Pismenny
> Subject: Re: Security enhancement proposal for kernel TLS
>
> On 07/31/18 10:45 AM, Vakul Garg
On 08/02/18 05:05 PM, Vakul Garg wrote:
> In case zerocopy_from_iter() fails, 'end' won't get marked.
> So fallback path is fine.
>
> > Which codepath is calling sg_nents()?
>
> While testing my WIP implementation of combined dynamic memory allocation for
> (aead_req || sgin || sgout || aad || i
On Thu, 02 Aug 2018 11:29:12 +0300, Petr Machata wrote:
> David Miller writes:
>
> > From: Jakub Kicinski
> > Date: Wed, 1 Aug 2018 17:00:47 -0700
> >
> >> On Wed, 1 Aug 2018 14:52:45 -0700, Saeed Mahameed wrote:
> >>> - According to the discussion outcome, we are keeping the congestion
>
> -Original Message-
> From: Dave Watson [mailto:davejwat...@fb.com]
> Sent: Thursday, August 2, 2018 10:17 PM
> To: Vakul Garg
> Cc: netdev@vger.kernel.org; bor...@mellanox.com;
> avia...@mellanox.com; da...@davemloft.net
> Subject: Re: [PATCH net-next] net/tls: Mark the end in scatter
On 08/02/18 09:50 PM, Vakul Garg wrote:
> Function decrypt_skb() made a bad assumption that number of sg entries
> required for mapping skb to be decrypted would always be less than
> MAX_SKB_FRAGS. The required count of sg entries for skb should always be
> calculated. If they cannot fit in local
On 08/02/18 08:43 PM, Vakul Garg wrote:
> Function zerocopy_from_iter() unmarks the 'end' in input sgtable while
> adding new entries in it. The last entry in sgtable remained unmarked.
> This results in KASAN error report on using apis like sg_nents(). Before
> returning, the function needs to mar
On 08/02/2018 09:05 AM, Andrew Lunn wrote:
>> I dont see any Reply's on the PC with tcpdump on PC
>
> So try ethool -S on the PC. Any packets dropped because of errors?
>
> Try turning off hardware checksums on the switch. ethtool -K.
Also make sure that cpsw is properly sending 64 bytes (inc
This refactoring work has been started by David Howells in cdfbabfb2f0c
(net: Work around lockdep limitation in sockets that use sockets) but
the exact same day in 581319c58600 (net/socket: use per af lockdep
classes for sk queues), Paolo Abeni added new classes.
This reduces the amount of (nearly
Make sure that the value of "(now - hc->tx_lsndtime) / hc->tx_rto" is
properly limited when shifting 'u32 cwnd' with it, otherwise we can get:
[40850.963623] UBSAN: Undefined behaviour in net/dccp/ccids/ccid2.c:237:7
[40851.043858] shift exponent 67 is too large for 32-bit type 'unsigned int'
[408
> I dont see any Reply's on the PC with tcpdump on PC
So try ethool -S on the PC. Any packets dropped because of errors?
Try turning off hardware checksums on the switch. ethtool -K.
Andrew
> Looks like a plan. So, I will remove the adjust_link speed
> selection for > 1g and the C45 support. I will leave the SS
> selection in dwxgmac2_core_init (patch 2/9) as this makes no
> difference because only 1g will be selected for now. I will also
> clearly refer in cover letter the BW results
On 02-08-2018 15:36, Andrew Lunn wrote:
>> Sorry, I made a mistake. Where it reads SGMII in my reply I was
>> referring to XGMII.
> So you have XGMII between the MAC and the PHY. That should support
> 2.5G, 5G and 10G. What i don't know is if you can also do 10/100/1000
> over XGMII?
Acording to d
On 08/02/2018 08:21 AM, Willem de Bruijn wrote:
> On Thu, Aug 2, 2018 at 9:21 AM Eric Dumazet wrote:
>>
>>
>>
>> On 08/02/2018 02:05 AM, Andrew Cann wrote:
>>> Hi,
>>>
>>> I posted this on stackoverflow yesterday but I'm reposting it here since it
>>> got
>>> no response. Original post:
>>> h
On Thu, Aug 2, 2018 at 9:21 AM Eric Dumazet wrote:
>
>
>
> On 08/02/2018 02:05 AM, Andrew Cann wrote:
> > Hi,
> >
> > I posted this on stackoverflow yesterday but I'm reposting it here since it
> > got
> > no response. Original post:
> > https://stackoverflow.com/questions/51630337/udp-packets-a
On 8/2/2018 4:40 AM, David Miller wrote:
From: Jakub Kicinski
Date: Wed, 1 Aug 2018 17:00:47 -0700
On Wed, 1 Aug 2018 14:52:45 -0700, Saeed Mahameed wrote:
- According to the discussion outcome, we are keeping the congestion control
setting as mlx5 device specific for the current HW ge
Hey Claire,
I'd be very interested to learn more.
Cheers,
Dwight
On Wed, Aug 1, 2018 at 1:50 PM, Claire Gagnon
wrote:
> Hello Dwight,
>
> Thanks for getting in touch!
>
> We’d be happy to consider publishing your content on our site, however, we
> do charge a fee for this.
>
> Please let me kn
Hi Andrew,
On Thu, Aug 2, 2018 at 3:45 PM, Andrew Lunn wrote:
>> I have PC connected to lan4(ip = 169.254..126.126) and the PC ip is
>> 169.254.78.251,
>> but when I ping from PC to lan4 I get Destination Host Unreachable,
>> but where as I can see
>> that in the tcpdump log for lan4 it does repl
> I have PC connected to lan4(ip = 169.254..126.126) and the PC ip is
> 169.254.78.251,
> but when I ping from PC to lan4 I get Destination Host Unreachable,
> but where as I can see
> that in the tcpdump log for lan4 it does reply back, but it doesn’t
> reach the PC, Is there I am missing
> someth
> Sorry, I made a mistake. Where it reads SGMII in my reply I was
> referring to XGMII.
So you have XGMII between the MAC and the PHY. That should support
2.5G, 5G and 10G. What i don't know is if you can also do 10/100/1000
over XGMII?
How are you currently connecting your 1G PHY to the MAC? XGM
Hi Andrew,
On 02-08-2018 15:03, Andrew Lunn wrote:
> On Thu, Aug 02, 2018 at 09:26:28AM +0100, Jose Abreu wrote:
>> Hi Andrew,
>>
>> Thanks for the review!
>>
>> On 01-08-2018 16:23, Andrew Lunn wrote:
@@ -842,6 +863,12 @@ static void stmmac_adjust_link(struct net_device *dev)
On Thu, Aug 02, 2018 at 09:36:41AM +0100, Jose Abreu wrote:
> Hi Andrew,
>
> On 01-08-2018 16:08, Andrew Lunn wrote:
> > Hi Jose
> >
> >> +static int stmmac_xgmac2_mdio_read(struct stmmac_priv *priv, int phyaddr,
> >> + int phyreg)
> >> +{
> >> + unsigned int mii_addre
On 18/08/02 (木) 22:53, Jesper Dangaard Brouer wrote:
On Thu, 2 Aug 2018 22:17:53 +0900
Toshiaki Makita wrote:
On 18/08/02 (木) 20:45, Jesper Dangaard Brouer wrote:
On Thu, 2 Aug 2018 19:55:09 +0900
Toshiaki Makita wrote:
+ headroom = frame->data - delta - (void *)frame;
Your cal
On Thu, Aug 02, 2018 at 09:26:28AM +0100, Jose Abreu wrote:
> Hi Andrew,
>
> Thanks for the review!
>
> On 01-08-2018 16:23, Andrew Lunn wrote:
> >> @@ -842,6 +863,12 @@ static void stmmac_adjust_link(struct net_device *dev)
> >>new_state = true;
> >>ctrl &
On Thu, 2 Aug 2018 22:17:53 +0900
Toshiaki Makita wrote:
> On 18/08/02 (木) 20:45, Jesper Dangaard Brouer wrote:
> > On Thu, 2 Aug 2018 19:55:09 +0900
> > Toshiaki Makita wrote:
> >
> >> + headroom = frame->data - delta - (void *)frame;
> >
> > Your calculation of headroom is still adding
On 08/02/2018 06:20 AM, Eric Dumazet wrote:
>
> Ideally you could give us a C reproducer, so that we can run it ourselves and
> fix the kernel bug if there is one.
>
> This C reproducer could be part of an official patch, adding a test in
> tools/testing/selftests/net
Alternatively a test i
On 08/02/2018 02:05 AM, Andrew Cann wrote:
> Hi,
>
> I posted this on stackoverflow yesterday but I'm reposting it here since it
> got
> no response. Original post:
> https://stackoverflow.com/questions/51630337/udp-packets-arriving-on-wrong-sockets-on-linux
>
> I have two UDP sockets bound
On 18/08/02 (木) 20:45, Jesper Dangaard Brouer wrote:
On Thu, 2 Aug 2018 19:55:09 +0900
Toshiaki Makita wrote:
+ headroom = frame->data - delta - (void *)frame;
Your calculation of headroom is still adding an assumption that
xdp_frame is located in the top of data area, that is unneces
+netdev and Saeed
On Thu, Aug 02, 2018 at 11:54:49AM +0300, Dan Carpenter wrote:
> Hello Tariq Toukan,
>
> The patch 0ec13877ce95: "net/mlx5e: Gather all XDP pre-requisite
> checks in a single function" from Mar 12, 2018, leads to the
> following Smatch warning:
>
> drivers/net/ethernet/mell
When a ICMPV6_PKT_TOOBIG is received from a link local address the pmtu will
be updated on a route with an arbitrary interface index. Subsequent packets
sent back to the same link local address may therefore end up not
considering the updated pmtu.
Current behavior breaks TAHI v6LC4.1.4 Reduce PMT
On Thu, 2 Aug 2018 19:55:09 +0900
Toshiaki Makita wrote:
> + headroom = frame->data - delta - (void *)frame;
Your calculation of headroom is still adding an assumption that
xdp_frame is located in the top of data area, that is unnecessary.
The headroom can be calculated as:
headroom = si
Function decrypt_skb() made a bad assumption that number of sg entries
required for mapping skb to be decrypted would always be less than
MAX_SKB_FRAGS. The required count of sg entries for skb should always be
calculated. If they cannot fit in local array sgin_arr[], allocate them
from heap irresp
Den ons 1 aug. 2018 kl 22:25 skrev Daniel Borkmann :
>
> On 08/01/2018 04:43 PM, Björn Töpel wrote:
> > Den ons 1 aug. 2018 kl 16:14 skrev Jesper Dangaard Brouer
> > :
> >> On Mon, 23 Jul 2018 11:41:02 +0200
> >> Björn Töpel wrote:
> >>
> >> diff --git a/net/core/xdp.c b/net/core/xdp.c
>
Move XDP and napi related fields from veth_priv to newly created veth_rq
structure.
When xdp_frames are enqueued from ndo_xdp_xmit and XDP_TX, rxq is
selected by current cpu.
When skbs are enqueued from the peer device, rxq is one to one mapping
of its peer txq. This way we have a restriction tha
This allows NIC's XDP to redirect packets to veth. The destination veth
device enqueues redirected packets to the napi ring of its peer, then
they are processed by XDP on its peer veth device.
This can be thought as calling another XDP program by XDP program using
REDIRECT, when the peer enables dr
We are going to add kern_flags field in redirect_info for kernel
internal use.
In order to avoid function call to access the flags, make redirect_info
accessible from modules. Also as it is now non-static, add prefix bpf_
to redirect_info.
v6:
- Fix sparse warning around EXPORT_SYMBOL.
Signed-off
This allows further redirection of xdp_frames like
NIC -> veth--veth -> veth--veth
(XDP) (XDP) (XDP)
The intermediate XDP, redirecting packets from NIC to the other veth,
reuses xdp_mem_info from NIC so that page recycling of the NIC works on
the destination veth's XDP.
In th
We need some mechanism to disable napi_direct on calling
xdp_return_frame_rx_napi() from some context.
When veth gets support of XDP_REDIRECT, it will redirects packets which
are redirected from other devices. On redirection veth will reuse
xdp_mem_info of the redirection source device to make retu
This is preparation for XDP TX and ndo_xdp_xmit.
This allows napi handler to handle xdp_frames through xdp ring as well
as sk_buff.
v7:
- Use xdp_scrub_frame() instead of memset().
v3:
- Revert v2 change around rings and use a flag to differentiate skb and
xdp_frame, since bulk skb xmit makes l
Oversized packets including GSO packets can be dropped if XDP is
enabled on receiver side, so don't send such packets from peer.
Drop TSO and SCTP fragmentation features so that veth devices themselves
segment packets with XDP enabled. Also cap MTU accordingly.
v4:
- Don't auto-adjust MTU but cap
xdp_frame has kernel pointers which should not be readable from bpf
programs. When we want to reuse xdp_frame region but it may be read by
bpf programs later, we can use this helper to clear kernel pointers.
This is more efficient than calling memset() for the entire struct.
Signed-off-by: Toshiak
This is the basic implementation of veth driver XDP.
Incoming packets are sent from the peer veth device in the form of skb,
so this is generally doing the same thing as generic XDP.
This itself is not so useful, but a starting point to implement other
useful veth XDP features like TX and REDIREC
This is needed for veth XDP which does skb_copy_expand()-like operation.
v2:
- Drop skb_copy_header part because it has already been exported now.
Signed-off-by: Toshiaki Makita
---
include/linux/skbuff.h | 1 +
net/core/skbuff.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
di
This patch set introduces driver XDP for veth.
Basically this is used in conjunction with redirect action of another XDP
program.
NIC ---> veth===veth
(XDP) (redirect)(XDP)
In this case xdp_frame can be forwarded to the peer veth without
modification, so we can expect far bette
Signed-off-by: Ganesh Goudar
---
net/core/skbuff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 266b954..51b0a912 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -1715,7 +1715,7 @@ void *skb_push(struct sk_buff *skb, uns
Function zerocopy_from_iter() unmarks the 'end' in input sgtable while
adding new entries in it. The last entry in sgtable remained unmarked.
This results in KASAN error report on using apis like sg_nents(). Before
returning, the function needs to mark the 'end' in the last entry it
adds.
Signed-o
Hi,
I posted this on stackoverflow yesterday but I'm reposting it here since it got
no response. Original post:
https://stackoverflow.com/questions/51630337/udp-packets-arriving-on-wrong-sockets-on-linux
I have two UDP sockets bound to the same address and connected to addresses A
and B. I have
Hi Andrew,
On 01-08-2018 16:08, Andrew Lunn wrote:
> Hi Jose
>
>> +static int stmmac_xgmac2_mdio_read(struct stmmac_priv *priv, int phyaddr,
>> + int phyreg)
>> +{
>> +unsigned int mii_address = priv->hw->mii.addr;
>> +unsigned int mii_data = priv->hw->mii.dat
David Miller writes:
> From: Jakub Kicinski
> Date: Wed, 1 Aug 2018 17:00:47 -0700
>
>> On Wed, 1 Aug 2018 14:52:45 -0700, Saeed Mahameed wrote:
>>> - According to the discussion outcome, we are keeping the congestion control
>>> setting as mlx5 device specific for the current HW generation.
Hi Andrew,
Thanks for the review!
On 01-08-2018 16:23, Andrew Lunn wrote:
>> @@ -842,6 +863,12 @@ static void stmmac_adjust_link(struct net_device *dev)
>> new_state = true;
>> ctrl &= ~priv->hw->link.speed_mask;
>> switch (phydev->sp
RoCE qps use a pair of physical queues (pq) received from the Queue Manager
(QM) - an offload queue (OFLD) and a low latency queue (LLT). The QM block
creates a pq for each TC, and allows RoCE qps to ask for a pq with a
specific TC. As a result, qps with different VLAN priorities can be mapped
to d
Hi Andrew,
Thank for your reply.
On Thu, Jul 26, 2018 at 4:39 PM, Andrew Lunn wrote:
>> I am bit confused on how dsa needs to be actually working,
>> Q's
>> 1] should I be running a dhcp server on eth1 (where switch is connected)
>> so that devices connected on lan* devices get an ip ?
>
> N
Distinguish not set offload_tc from offload_tc 0 and add getters and
setters.
Signed-off-by: Denis Bolotin
Signed-off-by: Ariel Elior
---
drivers/net/ethernet/qlogic/qed/qed.h | 3 +++
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 2 +-
drivers/net/ethernet/qlogic/qed/qed_dev.c | 32
The API receives a priority and looks for the TC it is mapped to in the
operational DCBX configuration.
Signed-off-by: Denis Bolotin
Signed-off-by: Ariel Elior
---
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 19 +++
drivers/net/ethernet/qlogic/qed/qed_dcbx.h | 1 +
2 files cha
From: Wei Yongjun
Fixes gcc '-Wunused-but-set-variable' warning:
net/rxrpc/proc.c: In function 'rxrpc_call_seq_show':
net/rxrpc/proc.c:66:29: warning:
variable 'nowj' set but not used [-Wunused-but-set-variable]
unsigned long timeout = 0, nowj;
^
Signed-off-by: W
Hi Dave,
This patch series adds support for multiple concurrent traffic classes for RoCE.
The first three patches enable the required parts of the driver to learn the TC
configuration, and the last one makes use of it to enable the feature.
Please consider applying this to net-next.
V1->V2:
--
89 matches
Mail list logo
