When we send a packet for our own local address on a non-loopback interface
(e.g. eth0), due to the change had been introduced from commit 0b922b7a829c
("net: original ingress device index in PKTINFO"), the original ingress
device index would be set as the loopback interface. However, the packet
sh
Thank you for your quick answer ! Allow me some days for this test :
1 - I am at work these days
2 - it has been a while since I have dealt with custom kernels, I am a
bit rusty, it will be good to review this topic
--
Robert Grasso
@home
---
UNIX was not designed to stop you from doing stupid
> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Tuesday, December 27, 2016 12:55 PM
> To: Kweh, Hock Leong
> Cc: joao.pi...@synopsys.com; peppe.cavall...@st.com;
> seraphin.bonna...@st.com; alexandre.tor...@gmail.com;
> manab...@gmail.com; niklas.cas...@axis.
> -Original Message-
> From: Florian Fainelli [mailto:f.faine...@gmail.com]
> Sent: Tuesday, December 27, 2016 1:14 PM
> To: Kweh, Hock Leong ; David S. Miller
> ; Joao Pinto ; Giuseppe
> CAVALLARO ; seraphin.bonna...@st.com
> Cc: Alexandre TORGUE ; Joachim Eastwood
> ; Niklas Cassel ; Joha
On 12/26/2016 09:10 PM, Florian Fainelli wrote:
>
>
> On 12/27/2016 03:44 AM, Kweh, Hock Leong wrote:
>> From: "Kweh, Hock Leong"
>>
>> If kernel module stmmac driver being loaded after OS booted, there is a
>> race condition between stmmac_open() and stmmac_mdio_register(), which is
>> invoke
On 12/27/2016 03:44 AM, Kweh, Hock Leong wrote:
> From: "Kweh, Hock Leong"
>
> If kernel module stmmac driver being loaded after OS booted, there is a
> race condition between stmmac_open() and stmmac_mdio_register(), which is
> invoked inside stmmac_dvr_probe(), and the error is showed in dmes
From: "Kweh, Hock Leong"
Date: Tue, 27 Dec 2016 19:44:59 +0800
> From: "Kweh, Hock Leong"
>
> If kernel module stmmac driver being loaded after OS booted, there is a
> race condition between stmmac_open() and stmmac_mdio_register(), which is
> invoked inside stmmac_dvr_probe(), and the e
>> #define NIC_MAX_RSS_HASH_BITS 8
>> #define NIC_MAX_RSS_IDR_TBL_SIZE (1 << NIC_MAX_RSS_HASH_BITS)
>> +#define NIC_TNS_RSS_IDR_TBL_SIZE 5
>
> So you want to use only 5 queues per VF when TNS is enabled, is it ??
> There are 4096 RSS indices in total, for each VF you can use
From: "Kweh, Hock Leong"
If kernel module stmmac driver being loaded after OS booted, there is a
race condition between stmmac_open() and stmmac_mdio_register(), which is
invoked inside stmmac_dvr_probe(), and the error is showed in dmesg log as
PHY not found and stmmac_open() failed:
[ 473.9193
On 2016年12月24日 03:31, Daniel Borkmann wrote:
Hi Jason,
On 12/23/2016 03:37 PM, Jason Wang wrote:
Since we use EWMA to estimate the size of rx buffer. When rx buffer
size is underestimated, it's usual to have a packet with more than one
buffers. Consider this is not a bug, remove the warning a
After commit 73b62bd085f4737679ea9afc7867fa5f99ba7d1b ("virtio-net:
remove the warning before XDP linearizing"), there's no users for
bpf_warn_invalid_xdp_buffer(), so remove it. This is a revert for
commit f23bc46c30ca5ef58b8549434899fcbac41b2cfc.
Cc: Daniel Borkmann
Cc: John Fastabend
Signed-o
On Mon, Dec 26, 2016 at 5:36 PM, Alexei Starovoitov
wrote:
> On Sat, Dec 24, 2016 at 08:59:53PM +0100, Daniel Borkmann wrote:
>> On 12/24/2016 03:22 AM, Andy Lutomirski wrote:
>> >BPF digests are intended to be used to avoid reloading programs that
>> >are already loaded. For use cases (CRIU?) wh
On Sat, Dec 24, 2016 at 08:59:53PM +0100, Daniel Borkmann wrote:
> On 12/24/2016 03:22 AM, Andy Lutomirski wrote:
> >BPF digests are intended to be used to avoid reloading programs that
> >are already loaded. For use cases (CRIU?) where untrusted programs
> >are involved, intentional hash collisio
Robert Grasso :
[dhcp snafu]
> First of all, can you confirm that I am doing right in posting to you
> (addresses found in README.Debian) ?
It isn't completely wrong.
> If I do, can you help ? I am not very proficient with Ethernet, and I am not
> able to figure out what my provider changed : th
On Mon, Dec 26, 2016 at 9:51 AM, Ard Biesheuvel
wrote:
> On 26 December 2016 at 07:57, Herbert Xu wrote:
>> On Sat, Dec 24, 2016 at 09:57:53AM -0800, Andy Lutomirski wrote:
>>>
>>> I actually do use incremental hashing later on. BPF currently
>>> vmallocs() a big temporary buffer just so it can
On 26 December 2016 at 07:57, Herbert Xu wrote:
> On Sat, Dec 24, 2016 at 09:57:53AM -0800, Andy Lutomirski wrote:
>>
>> I actually do use incremental hashing later on. BPF currently
>> vmallocs() a big temporary buffer just so it can fill it and hash it.
>> I change it to hash as it goes.
>
> H
From: Vincent Bernat
Date: Sun, 25 Dec 2016 08:44:40 +0100
> ❦ 24 novembre 2016 10:55 +0100, Miroslav Lichvar :
>
>> The ETHTOOL_GLINKSETTINGS command is deprecating the ETHTOOL_GSET
>> command and likewise it shouldn't require the CAP_NET_ADMIN
>> capability.
>
> Could this patch be pushed t
From: Matthias Tafelmeier
Date: Mon, 26 Dec 2016 17:43:08 +0100
>
>> From: Matthias Tafelmeier
>> Date: Mon, 26 Dec 2016 10:49:23 +0100
>>
>>> @@ -269,13 +269,21 @@ static struct ctl_table net_core_table[] = {
>>> .extra1 = &min_rcvbuf,
>>> },
>>> {
>>> - .
From: Mart van Santen
Date: Fri, 23 Dec 2016 16:09:23 +0100
> This patch fixes an issue where counters in the queue have type int,
> while the counters of the vif itself are specified as long. This can
> cause incorrect reporting of tx/rx values of the vif interface.
> More extensively reported o
Networking stack accelerate vlan tag handling by
keeping topmost vlan header in skb. This works as
long as packet remains in OVS datapath. But during
OVS upcall vlan header is pushed on to the packet.
When such packet is sent back to OVS datapath, core
networking stack might not handle it correctly
On Sun 2016-12-25 21:15:40, Arend Van Spriel wrote:
> On 24-12-2016 17:52, Pali Rohár wrote:
> > NVS calibration data for wl1251 are model specific. Every one device with
> > wl1251 chip has different and calibrated in factory.
> >
> > Not all wl1251 chips have own EEPROM where are calibration dat
From: Florian Fainelli
Date: Fri, 23 Dec 2016 19:56:56 -0800
> Commit beb0babfb77e ("korina: disable napi on close and restart")
> introduced calls to napi_disable() that were missing before,
> unfortunately this leaves a small window during which NAPI has a chance
> to run, yet we just freed res
From: Daniel Borkmann
Date: Wed, 21 Dec 2016 18:04:11 +0100
> Shahar reported a soft lockup in tc_classify(), where we run into an
> endless loop when walking the classifier chain due to tp->next == tp
> which is a state we should never run into. The issue only seems to
> trigger under load in th
On Monday 26 December 2016 16:43:53 Pavel Machek wrote:
> Hi!
>
> > > > NVS calibration data for wl1251 are model specific. Every one
> > > > device with wl1251 chip has different and calibrated in
> > > > factory.
> > > >
> > > > Not all wl1251 chips have own EEPROM where are calibration data
>
From: Matthias Tafelmeier
Date: Mon, 26 Dec 2016 10:49:23 +0100
> @@ -269,13 +269,21 @@ static struct ctl_table net_core_table[] = {
> .extra1 = &min_rcvbuf,
> },
> {
> - .procname = "dev_weight",
> - .data = &weight_p,
> +
Hi!
> > > NVS calibration data for wl1251 are model specific. Every one
> > > device with wl1251 chip has different and calibrated in factory.
> > >
> > > Not all wl1251 chips have own EEPROM where are calibration data
> > > stored. And in that case there is no "standard" place. Every
> > > devic
On Mon, Dec 26, 2016 at 02:04:27PM +, Koteshwar Rao, Satha wrote:
> Hi Sunil,
>
> In RFC cover letter we explained the feature details, files organized based
> on their supporting functionality, let me know if you are interested in any
> specific details
Please don't top post. Also, please
Thanks Sunil, will fix this in next version
Thanks,
Satha
From: Goutham, Sunil
Sent: Wednesday, December 21, 2016 1:20 AM
To: Koteshwar Rao, Satha; linux-ker...@vger.kernel.org
Cc: r...@kernel.org; da...@davemloft.net; Daney, David; Vatsavayi, Raghu;
Chickles, Derek; Romanov, Philip; netdev@vge
Hi Sunil,
In RFC cover letter we explained the feature details, files organized based on
their supporting functionality, let me know if you are interested in any
specific details
Thanks,
Satha
-Original Message-
From: Sunil Kovvuri [mailto:sunil.kovv...@gmail.com]
Sent: Wednesday, Dec
Responses inline
Thanks,
Satha
-Original Message-
From: Sunil Kovvuri [mailto:sunil.kovv...@gmail.com]
Sent: Wednesday, December 21, 2016 5:05 AM
To: Koteshwar Rao, Satha
Cc: LKML; Goutham, Sunil; Robert Richter; David S. Miller; Daney, David;
Vatsavayi, Raghu; Chickles, Derek; Romanov,
Thanks for suggestion. Will clean up code in next revision
Thanks,
Satha
-Original Message-
From: Sunil Kovvuri [mailto:sunil.kovv...@gmail.com]
Sent: Wednesday, December 21, 2016 4:44 AM
To: Koteshwar Rao, Satha
Cc: LKML; Goutham, Sunil; Robert Richter; David S. Miller; Daney, David;
V
Hi Sunil,
Thanks for review. Answers inline.
Thanks,
Satha.
-Original Message-
From: Sunil Kovvuri [mailto:sunil.kovv...@gmail.com]
Sent: Wednesday, December 21, 2016 4:36 AM
To: Koteshwar Rao, Satha
Cc: LKML; Goutham, Sunil; Robert Richter; David S. Miller; Daney, David;
Vatsavayi, Ra
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Tushar Dave
> Sent: Tuesday, December 06, 2016 1:07 AM
> To: jeffrey.t.kirs...@intel.com; intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org
> Subject: [RFC PATCH] i40
Oftenly, introducing side effects on packet processing on the other half
of the stack by adjusting one of TX/RX via sysctl is not desirable.
There are cases of demand for asymmetric, orthogonal configurability.
This holds true especially for nodes where RPS for RFS usage on top is
configured and t
> -Original Message-
> From: maowenan
> Sent: Saturday, December 24, 2016 4:30 PM
> To: 'Alexander Duyck'
> Cc: Jeff Kirsher; Stephen Hemminger; netdev@vger.kernel.org; weiyongjun (A);
> Dingtianhong; Wangzhou (B)
> Subject: RE: [PATCH] ethtool: add one ethtool option to set relax orderin
Andy Lutomirski wrote:
> Since there are plenty of uses for the new-in-4.10 BPF digest feature
> that would be problematic if malicious users could produce collisions,
> the BPF digest should be collision-resistant. SHA-1 is no longer
> considered collision-resistant, so switch it to SHA-256.
>
Hello,
I am a senior Linux sysadmin.
At home, I am using a Shuttle DS47 barebones computer as my firewall; it
contains the following two network cards :
01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE
802.11b/g/n WiFi Adapter (rev 01)
02:00.0 Ethernet controller: Realtek S
37 matches
Mail list logo
