Re: question regarding Linux kernel handling of packets received that has src address of interface address

On Fri, 5 Oct 2018, Ido Schimmel wrote: Did you set 'accept_local' [1] ? I did not. Thanks for the pointer, looks like exactly what I was looking for! -- Mikael Abrahamssonemail: swm...@swm.pp.se

Re: question regarding Linux kernel handling of packets received that has src address of interface address

On Fri, Oct 05, 2018 at 10:50:24AM +0200, Mikael Abrahamsson wrote: > So my question is where in the Linux kernel is this check performed that > disallows incoming packets that have src IP address the same as an interface > address? Can it be turned off? Is there a way to &qu

question regarding Linux kernel handling of packets received that has src address of interface address

address, which is fine for the DHCPv6-PD case (I have plenty of LAN addresses to choose from), but it doesn't work for the IPv6 IA_NA and IPv4 case. I have to use my source address to pass the BNG anti-spoofing filters. So my question is where in the Linux kernel is this check performed that disa

Re: mv88e6xxx: question: can switch irq be shared?

From: Marek Behún Date: Fri, 17 Aug 2018 11:30:55 +0200 > -IRQF_ONESHOT | IRQF_TRIGGER_FALLING, > +IRQF_ONESHOT | IRQF_TRIGGER_FALLING > +| IRQF_SHARED, The "|" operator shoudl end a line not start

Re: mv88e6xxx: question: can switch irq be shared?

On Fri, Aug 17, 2018 at 11:30:55AM +0200, Marek Behún wrote: > Hello, I am wondering if the main device irq in > dsa/mv88e6xxx/chip.c can be requested as shared (see patch below). This probably works O.K, but its not something anybody else has done. So there could be some hidden issues.

mv88e6xxx: question: can switch irq be shared?

Hello, I am wondering if the main device irq in dsa/mv88e6xxx/chip.c can be requested as shared (see patch below). The reason is that our board is wired so that irqs from all switches come to the same gpio. Marek --- drivers/net/dsa/mv88e6xxx/chip.c | 3 ++- 1 file changed, 2 insertions(+), 1

Re: pahole + BTF was: Re: [Question] bpf: about a new 'tools/bpf/bpf_dwarf2btf'

On Thu, Jul 26, 2018 at 04:21:31AM +0900, Taeung Song wrote: > > > On 07/26/2018 03:27 AM, Taeung Song wrote: > > Hi Arnaldo, > > > > On 07/26/2018 02:52 AM, Arnaldo Carvalho de Melo wrote: > > > Em Thu, Jul 26, 2018 at 02:23:32AM +0900, Taeung Song escreveu: > > > > Hi, > > > > > > > >

Re: pahole + BTF was: Re: [Question] bpf: about a new 'tools/bpf/bpf_dwarf2btf'

On 07/26/2018 03:27 AM, Taeung Song wrote: Hi Arnaldo, On 07/26/2018 02:52 AM, Arnaldo Carvalho de Melo wrote: Em Thu, Jul 26, 2018 at 02:23:32AM +0900, Taeung Song escreveu: Hi, Building bpf programs with .BTF section, I thought it'd be better to convert dwarf info to .BTF by a new tool

Re: pahole + BTF was: Re: [Question] bpf: about a new 'tools/bpf/bpf_dwarf2btf'

On 07/25/2018 08:27 PM, Taeung Song wrote: > On 07/26/2018 02:52 AM, Arnaldo Carvalho de Melo wrote: [...] >> BTW, Daniel, I just pushed to pahole's main repository at: >> >>    git://git.kernel.org/pub/scm/devel/pahole/pahole.git >> >> with the Martin's BTF patch, so no need to pull from the

Re: pahole + BTF was: Re: [Question] bpf: about a new 'tools/bpf/bpf_dwarf2btf'

Hi Arnaldo, On 07/26/2018 02:52 AM, Arnaldo Carvalho de Melo wrote: Em Thu, Jul 26, 2018 at 02:23:32AM +0900, Taeung Song escreveu: Hi, Building bpf programs with .BTF section, I thought it'd be better to convert dwarf info to .BTF by a new tool such as 'tools/bpf/bpf_dwarf2btf' instead of

[Question] bpf: about a new 'tools/bpf/bpf_dwarf2btf'

Hi, Building bpf programs with .BTF section, I thought it'd be better to convert dwarf info to .BTF by a new tool such as 'tools/bpf/bpf_dwarf2btf' instead of pahole in the future. Currently for bpf binary that have .BTF section, we need to use pahole from

Re: Question about force_primary in bonding driver

From: Xiangning Yu Date: Wed, 6 Jun 2018 03:18:23 -0700 > diff --git a/drivers/net/bonding/bond_options.c > b/drivers/net/bonding/bond_options.c > index 58c705f..b594bae 100644 > --- a/drivers/net/bonding/bond_options.c > +++ b/drivers/net/bonding/bond_options.c > @@ -1142,6 +1142,7 @@ static

Question about force_primary in bonding driver

Hi netdev folks, While playing with bonding active-standby mode, we found a possible timing issue that the primary might not initialized in bond_enslave(): if (bond_uses_primary(bond) && bond->params.primary[0]) { /* if there is a primary slave, remember it */

[QUESTION] ehea memory notifier

Hi, looking at the ehea_mem_notifier() and called functions, I wonder if it can tolerate addresses and sizes that are not aligned to EHEA_SECTSIZE. Looks like for MEM_ONLINE/MEM_GOING_OFFLINE ehea_update_busmap() will do nothing in case we don't span at least one EHEA_SECTSIZE. This implies,

Re: One question about __tcp_select_window()

Thanks for your reply, Eric. Actually, this is a query about the code while I am reading code. >From my instinct and the comment, I think we should choose the bigger one but maybe I miss something(like your said, autotuning) Anyway, I will read more codes and do more tests. Thanks. On Tue, Apr

Re: One question about __tcp_select_window()

On 04/17/2018 06:53 AM, Wang Jian wrote: > I test the fix with 4.17.0-rc1+ and it seems work. > > 1. iperf -c IP -i 20 -t 60 -w 1K > with-fix vs without-fix : 1.15Gbits/sec vs 1.05Gbits/sec > I also try other windows and have similar results. > > 2. Use tcp probe trace snd_wind. > with-fix vs

Re: One question about __tcp_select_window()

I test the fix with 4.17.0-rc1+ and it seems work. 1. iperf -c IP -i 20 -t 60 -w 1K with-fix vs without-fix : 1.15Gbits/sec vs 1.05Gbits/sec I also try other windows and have similar results. 2. Use tcp probe trace snd_wind. with-fix vs without-fix: 1245568 vs 1042816 3. I don't see extra

One question about __tcp_select_window()

Hi all, While I read __tcp_select_window() code, I find that it maybe return a smaller window. Below is one scenario I thought, may be not right: In function __tcp_select_window(), assume: full_space is 6mss, free_space is 2mss, tp->rcv_wnd is 3MSS. And assume disable window scaling, then window

Re: TCP one-by-one acking - RFC interpretation question

On Wed, Apr 11, 2018 at 5:06 AM, Michal Kubecek wrote: > On Wed, Apr 11, 2018 at 12:58:37PM +0200, Michal Kubecek wrote: >> There is something else I don't understand, though. In the case of >> acking previously sacked and never retransmitted segment, >> tcp_clean_rtx_queue()

Re: TCP one-by-one acking - RFC interpretation question

On Wed, Apr 11, 2018 at 12:58:37PM +0200, Michal Kubecek wrote: > There is something else I don't understand, though. In the case of > acking previously sacked and never retransmitted segment, > tcp_clean_rtx_queue() calculates the parameters for tcp_ack_update_rtt() > using > > if

Re: TCP one-by-one acking - RFC interpretation question

On Fri, Apr 06, 2018 at 09:49:58AM -0700, Eric Dumazet wrote: > Cc Neal and Yuchung if they missed this thread. > > On 04/06/2018 08:03 AM, Michal Kubecek wrote: > > On Fri, Apr 06, 2018 at 05:01:29AM -0700, Eric Dumazet wrote: > >> > >> > >> On 04/06/2018 03:05 AM, Michal Kubecek wrote: > >>>

Re: TCP one-by-one acking - RFC interpretation question

Cc Neal and Yuchung if they missed this thread. On 04/06/2018 08:03 AM, Michal Kubecek wrote: > On Fri, Apr 06, 2018 at 05:01:29AM -0700, Eric Dumazet wrote: >> >> >> On 04/06/2018 03:05 AM, Michal Kubecek wrote: >>> Hello >>> >>> I encountered a strange behaviour of some (non-linux) TCP stack

Re: TCP one-by-one acking - RFC interpretation question

On Fri, Apr 06, 2018 at 05:01:29AM -0700, Eric Dumazet wrote: > > > On 04/06/2018 03:05 AM, Michal Kubecek wrote: > > Hello, > > > > I encountered a strange behaviour of some (non-linux) TCP stack which > > I believe is incorrect but support engineers from the company producing > > it claim is

Re: TCP one-by-one acking - RFC interpretation question

dition from RFC 2018 > section 3. Therefore Linux 4.4 stack ignores this SACK block, detects > (spurious) SACK reneging and unmarks the "previously sacked" flag of > segment 3 so that when second ACK arrives, there is no trace of it > having been sacked before. They already

TCP one-by-one acking - RFC interpretation question

eviously sacked" flag of segment 3 so that when second ACK arrives, there is no trace of it having been sacked before. They already admitted this SACK block is incorrect but there is still disagreement about the "one-by-one acking" behaviour in general. My question is: is my

A question about inet_csk_bind_conflict

HI all, I have a question about tcp bind check function:inet_csk_bind_conflict. My case: 192.168.56.101:37818==> 192.168.56.193:22 On host A (tcp client: 192.168.56.101), there is a tcp connection to server B(192.168.56.193, tcp server). I want run a tcp server on A, and listen/bind

Re: [QUESTION] Mainline support for B43_PHY_AC wifi cards

On 24/03/18 00:01, Rafał Miłecki wrote: > On 23 March 2018 at 15:09, Juri Lelli wrote: > > On 23/03/18 14:43, Rafał Miłecki wrote: > >> Hi, > >> > >> On 23 March 2018 at 10:47, Juri Lelli wrote: > >> > I've got a Dell XPS 13 9343/0TM99H (BIOS A15

Re: [QUESTION] Mainline support for B43_PHY_AC wifi cards

Radio: Manuf 0x17F, ID 0x2069, Revision 4, Version 0 >> > BUG: unable to handle kernel NULL pointer dereference at >> >> This isn't really useful without a full backtrace. > > Sure. I cut it here because I didn't expect people to debug what is > already

Re: [QUESTION] Mainline support for B43_PHY_AC wifi cards

N found (core revision 42) > > b43-phy0: Found PHY: Analog 12, Type 11 (AC), Revision 1 > > b43-phy0: Found Radio: Manuf 0x17F, ID 0x2069, Revision 4, Version 0 > > BUG: unable to handle kernel NULL pointer dereference at > > This isn't really useful without a

Re: [QUESTION] Mainline support for B43_PHY_AC wifi cards

bcma: bus0: Bus registered > b43-phy0: Broadcom 4352 WLAN found (core revision 42) > b43-phy0: Found PHY: Analog 12, Type 11 (AC), Revision 1 > b43-phy0: Found Radio: Manuf 0x17F, ID 0x2069, Revision 4, Version 0 > BUG: unable to handle kernel NULL pointer dereference at 0

[QUESTION] Mainline support for B43_PHY_AC wifi cards

: unable to handle kernel NULL pointer dereference at So, question: is replacing my card the only way I can get rid of this downstream dependency? :( Thanks a lot. Best, - Juri [1] https://elixir.bootlin.com/linux/v4.16-rc6/source/drivers/net/wireless/broadcom/b43/Kconfig#L151

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

... yes I've just noticed Russell's patch mentioning mvneta, and found the phylink patches to mvneta in net-next (until then I'd been reading the vanilla, where they haven't landed yet). https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tre

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

> Looking at the i2c dumps, and some past dumps from the igb driver, > it's dawning on me on me that the igb driver, without much hacking, > would try to read the PHY ID from the DMI/DDM block - a case which > the drivers/net/phy/mdio-i2c.c specifically avoids :-) It avoids if for a very good

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

> I was also wondering if someone has written any kernel-space support > for the SFP's. Sure enough, I've found lots of code by Russell King > under drivers/net/phy. I started reading from sfp.c, went on to > sfp-bus.c, next the phylink stuff... Answers lots of my questions. > Clearly someone

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

On 21 Mar 2018 at 11:47, Andrew Lunn , net...@vger.ker wrote: > Another question is, how to write the driver's initialization > sequence, for it to correctly decide if the SFP is SERDES or SGMII or > what. I could just follow the config obtained from the i210 EEPROM. > Alternatively

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

se which the drivers/net/phy/mdio-i2c.c specifically avoids :-) My current opinion about the matters is, that I don't really need a valid SPD EEPROM to initialize the PHY in the SFP. The question is, if I can make the i210 properly handshake with the PHY on the SGMII payload lane. Another question is,

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

On 20 Mar 2018 at 13:09, Andrew Lunn wrote: > > i2cdetect has found three i2c slaves (identical layout in both SFP's) > > at addresses 0x50, 0x51 and 0x56. > > What are they? EEPROM, DDM and "MDIO over i2c" ? > > The SFP's likely lack a proper SFP MSA data structure. > > 0x50 and 0x51 are EEPROM

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

> i2cdetect has found three i2c slaves (identical layout in both SFP's) > at addresses 0x50, 0x51 and 0x56. > What are they? EEPROM, DDM and "MDIO over i2c" ? > The SFP's likely lack a proper SFP MSA data structure. 0x50 and 0x51 are EEPROM like. See drivers/net/phy/sfp.c. The standard at24

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

I've taken a look inside the two SFP's. http://support.fccps.cz/download/adv/frr/ptp/inside_sfps.zip The uglier, bigger and likely older model (my SFP#2) contains two PCB's sandwiched, and the key chips are inside the sandwich. Thus, the photoes don't show much. The sexier SFP#1 = the one with

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

> I'm not getting an ACK from the SFP, probably because I've got the > address and offset wrong and because I'd better use indirect access. > There's some more work awaiting me... Try address 0x50. i2detect will probe all addresses for you, if you have a standard Linux i2c bus. Andrew

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

> > > Right now I've modded igb_init_i2c() to engage the bit-banging > > > i2c driver for the i210 too > > > > I don't think that will work. The datasheet for the i210 talks about > > two registers for I2C/MDIO which are not bit-banging. Only the i350 > > uses bit-banging. > > > From the i210

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

On 17 Mar 2018 at 15:50, Andrew Lunn wrote: > On Sat, Mar 17, 2018 at 08:39:00AM +0100, Frantisek Rysanek wrote: > > On 16 Mar 2018 at 22:02, Andrew Lunn wrote: > > > > > > Does ethtool -m show anything useful? > > > > > > > Not much. "unsupported". > > static int igb_get_module_info(struct

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

On Sat, Mar 17, 2018 at 08:39:00AM +0100, Frantisek Rysanek wrote: > On 16 Mar 2018 at 22:02, Andrew Lunn wrote: > > > > Does ethtool -m show anything useful? > > > > Not much. "unsupported". static int igb_get_module_info(struct net_device *netdev, struct

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

On 16 Mar 2018 at 22:02, Andrew Lunn wrote: > > Does ethtool -m show anything useful? > Not much. "unsupported". Probably the ioctl() is not implemented or something, I haven't investigated. Maybe I should. Right now I've modded igb_init_i2c() to engage the bit-banging i2c driver for the i210

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

> The DeLock board is this beauty: > http://www.delock.de/produkte/G_89481/merkmale.html?setLanguage=en > DeLock techsupport were so kind as to provide me with a schematic > snippet, showing the wiring of the i210 fiber SKU's dedicated > I2C/MDIO pins to the SFP socket's standard I2C pins. There

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

Intel reference design. The board works just fine. Interesting - I've noticed before that the sparse Broadcom data brief for the BCM5461S doesn't cotain a word about 100Base-FX. This might be a good question to the SFP vendor's techsupport :-) The 54616S datasheet does mention 100Base-FX, bu

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

On Fri, Mar 16, 2018 at 05:48:20PM +0100, Frantisek Rysanek wrote: > Dear polite inhabitants of the "netdev" mailing list, > > this is for a skunkworks project at the fringe of my job... > More of a DIY hobby thing :-) I'm tinkering and having fun. > > The wizards from linux-ptp have taught me

HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

Dear polite inhabitants of the "netdev" mailing list, this is for a skunkworks project at the fringe of my job... More of a DIY hobby thing :-) I'm tinkering and having fun. The wizards from linux-ptp have taught me how to use the i210 for precise timestamping, which works fine at all copper

Re: question about bpf.test_progs.fail

Hi Shaoting, On 03/12/2018 02:52 AM, lst wrote: > hi, I have a question need your help. > > I get failure "libbpf: incorrect bpf_call opcode" when running below two > cases on v4.16-rc3: > - > test_l4lb_all(); >     const char *

question about bpf.test_progs.fail

hi, I have a question need your help. I get failure "libbpf: incorrect bpf_call opcode" when running below two cases on v4.16-rc3: - test_l4lb_all();     const char *file2 = "./test_l4lb_noinline.o"; test_xdp_noinline();

Re: A TLP implementation question

On 02/13/18 at 05:11P, Yuchung Cheng wrote: > On Tue, Feb 13, 2018 at 4:27 PM, hiren panchasara > wrote: > > > > Looking at current net-next to understand an aspect of TLP (tail loss > > probe) implementation. > > > > https://tools.ietf.org/html/draft-ietf-tcpm-rack-02

Re: A TLP implementation question

On Tue, Feb 13, 2018 at 4:27 PM, hiren panchasara wrote: > > Looking at current net-next to understand an aspect of TLP (tail loss > probe) implementation. > > https://tools.ietf.org/html/draft-ietf-tcpm-rack-02 is the source of > truth now for TLP and 6.2.1. Phase 1:

A TLP implementation question

Looking at current net-next to understand an aspect of TLP (tail loss probe) implementation. https://tools.ietf.org/html/draft-ietf-tcpm-rack-02 is the source of truth now for TLP and 6.2.1. Phase 1: Scheduling a loss probe Step 1: Check conditions for scheduling a PTO. has following as one of

Re: net: phy: question about phy_is_internal for generic-phy

at the end of last year. > > How are the MDIO busses arranged? Is there an internal MDIO bus and an > external MDIO bus? How do you change between the internal and the > external? Or is it one bus, with the two PHYs having different > addresses? > > For the hardware in question last

Re: [Resend] Question: kselftests: bpf/test_maps failed

On Fri, Feb 09, 2018 at 03:01:57PM +0100, Daniel Borkmann wrote: > On 02/09/2018 06:14 AM, Li Zhijian wrote: > > Hi > > > > INTEL 0-Day noticed that bpf/test_maps has different results at different > > platforms. > > when it fails, the details are like > > Sorry for the late reply and thanks

Re: net: phy: question about phy_is_internal for generic-phy

change between the internal and the external? Or is it one bus, with the two PHYs having different addresses? For the hardware in question last year, an MDIO MUX was implemented. The MAC has a phy-handle pointing to either the internal PHY on the internal MDIO bus, or the external PHY on the externa

Re: net: phy: question about phy_is_internal for generic-phy

Hi Andrew, On Thu, 8 Feb 2018 13:51:44 +0100 wrote: > On Thu, Feb 08, 2018 at 07:09:25PM +0900, Kunihiko Hayashi wrote: > > Hello, > > > > Is there a way to specify "phy is internal" to generic phy driver, > > that is, to make phy_is_internal() function available? > > > > I

Re: net: phy: question about phy_is_internal for generic-phy

On Thu, Feb 08, 2018 at 07:09:25PM +0900, Kunihiko Hayashi wrote: > Hello, > > Is there a way to specify "phy is internal" to generic phy driver, > that is, to make phy_is_internal() function available? > > I found "phy-is-integrated" DT property in >

net: phy: question about phy_is_internal for generic-phy

Hello, Is there a way to specify "phy is internal" to generic phy driver, that is, to make phy_is_internal() function available? I found "phy-is-integrated" DT property in Documentation/devicetree/bindings/net/phy.txt, however, it seems that the property is no effect for generic phy. And I think

Re: net: r8169: a question of memory barrier in the r8169 driver

Jia-Ju Bai : > > On 2018/1/19 9:11, Francois Romieu wrote: > > Jia-Ju Bai : > > [...] > > > The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR: > > > if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) { >

Re: net: r8169: a question of memory barrier in the r8169 driver

Peter Zijlstra : > On Fri, Jan 19, 2018 at 02:11:18AM +0100, Francois Romieu wrote: > > Peter Zijlstra : > > [...] > > > There is only 1 variable afaict. Memory barriers need at least 2 in > > > order to be able to do _anything_. > > > > I don't get

Re: net: r8169: a question of memory barrier in the r8169 driver

On Fri, Jan 19, 2018 at 02:11:18AM +0100, Francois Romieu wrote: > Peter Zijlstra : > [...] > > There is only 1 variable afaict. Memory barriers need at least 2 in > > order to be able to do _anything_. > > I don't get your point: why don't {cur_tx, dirty_tx} qualify as

Re: net: r8169: a question of memory barrier in the r8169 driver

On 2018/1/19 9:11, Francois Romieu wrote: Jia-Ju Bai : [...] The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR: if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) { netif_err(tp, drv, dev, "BUG! Tx Ring full when

Re: net: r8169: a question of memory barrier in the r8169 driver

Jia-Ju Bai : [...] > The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR: > if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) { > netif_err(tp, drv, dev, "BUG! Tx Ring full when queue awake!\n"); > goto err_stop_0; >

Re: net: r8169: a question of memory barrier in the r8169 driver

Peter Zijlstra : [...] > There is only 1 variable afaict. Memory barriers need at least 2 in > order to be able to do _anything_. I don't get your point: why don't {cur_tx, dirty_tx} qualify as said two variables ? -- Ueimor

Re: net: r8169: a question of memory barrier in the r8169 driver

On Thu, Jan 18, 2018 at 10:06:17PM +0800, Jia-Ju Bai wrote: > In the rt8169 driver, the function "rtl_tx" uses "smp_mb" to sync the > writing operation with rtl8169_start_xmit: > if (tp->dirty_tx != dirty_tx) { > tp->dirty_tx = dirty_tx; > smp_mb(); > ... > } > The

net: r8169: a question of memory barrier in the r8169 driver

In the rt8169 driver, the function "rtl_tx" uses "smp_mb" to sync the writing operation with rtl8169_start_xmit: if (tp->dirty_tx != dirty_tx) { tp->dirty_tx = dirty_tx; smp_mb(); ... } The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR:

question about __netif_receive_skb_core() work on macvlan device

Hi, I have a question about __netif_receive_skb_core(), 1. create a macvlan device on a real ethernet device and configure a mac address to this macvlan device 2. create a AF_PACKET socket and bind to the real ethernet device in step 1 3. user application will receive packet which destination

Re: [QUESTION] Doubt about NAPI_GRO_CB(skb)->is_atomic in tcpv4 gro process

ue was based on an atomic >>>>>> * datagram we can overwrite the value and ignore it. >>>>>> */ >>>>>> if (NAPI_GRO_CB(skb)->is_atomic) >>>>>> //we che

Re: [QUESTION] Doubt about NAPI_GRO_CB(skb)->is_atomic in tcpv4 gro process

t;>>> if (NAPI_GRO_CB(skb)->is_atomic) >>>>> //we check it here >>>>> NAPI_GRO_CB(p)->flush_id = flush_id; >>>>> else >>>>> NAPI_GRO_CB(p)->flush_

Re: [QUESTION] Doubt about NAPI_GRO_CB(skb)->is_atomic in tcpv4 gro process

overwrite the value and ignore it. >>>> */ >>>> if (NAPI_GRO_CB(skb)->is_atomic) //we >>>> check it here >>>> NAPI_GRO_CB(p)->flush_id = flush_id; >>>>

Re: [QUESTION] Doubt about NAPI_GRO_CB(skb)->is_atomic in tcpv4 gro process

;>> NAPI_GRO_CB(p)->flush_id = flush_id; >>> else >>> NAPI_GRO_CB(p)->flush_id |= flush_id; >>> } >>> >>> NAPI_GRO_CB(skb)->is_atomic = !!(iph->frag_off

Re: [QUESTION] Doubt about NAPI_GRO_CB(skb)->is_atomic in tcpv4 gro process

} >> >> NAPI_GRO_CB(skb)->is_atomic = !!(iph->frag_off & htons(IP_DF)); >> //we set it here >> NAPI_GRO_CB(skb)->flush |= flush; >> skb_set_network_header(skb, off); >> >> } >> >> My ques

Re: [QUESTION] Doubt about NAPI_GRO_CB(skb)->is_atomic in tcpv4 gro process

d = flush_id; > else > NAPI_GRO_CB(p)->flush_id |= flush_id; > } > > NAPI_GRO_CB(skb)->is_atomic = !!(iph->frag_off & htons(IP_DF)); //we > set it here > NAPI_GRO_CB(skb)->flush |= flush; > skb_set_

[QUESTION] Doubt about NAPI_GRO_CB(skb)->is_atomic in tcpv4 gro process

re NAPI_GRO_CB(skb)->flush |= flush; skb_set_network_header(skb, off); .... } My question is whether we should check the NAPI_GRO_CB(skb)->is_atomic or NAPI_GRO_CB(p)->is_atomic? If we should check NAPI_GRO_CB(skb)->is_atomic, then maybe it is unnec

Re: question lan9303: DSA concurrency and locking,

On 15. nov. 2017 15:08, Andrew Lunn wrote: On Wed, Nov 15, 2017 at 01:08:22PM +0100, Egil Hjelmeland wrote: Hi experts Hi, thanks for response, both Andrew and Vivien! I am hoping for some guidance. Does DSA offer any protection against concurrent calls of dsa_switch_ops? Hi Egil DSA

Re: question lan9303: DSA concurrency and locking,

Hi, >> Does DSA offer any protection against concurrent calls of >> dsa_switch_ops? This is something I thought about for a while. Since DSA offers an abstraction of different net stack entry points to its drivers, like netlink (bridge, etc.) or ioctl (ethtool), it would make sense to add a

Re: question lan9303: DSA concurrency and locking,

On Wed, Nov 15, 2017 at 01:08:22PM +0100, Egil Hjelmeland wrote: > Hi experts > > I am hoping for some guidance. > > Does DSA offer any protection against concurrent calls of dsa_switch_ops? Hi Egil DSA itself does not. There are various upper locks, which protect some calls, in some ways.

question lan9303: DSA concurrency and locking,

Hi experts I am hoping for some guidance. Does DSA offer any protection against concurrent calls of dsa_switch_ops? I did not include any locking in the code I contributed to lan9303. First I felt bad locking is worse than no locking. Second I assumed that reviewers would point out if

Re: SKB Reference Question

From: Joe Smith Date: Wed, 1 Nov 2017 10:27:49 -0700 > How strictly are references on the SKB enforced. For example, > tcp_transmit_skb() clones the SKB and adds a TCP header. Can I assume > that in case of re-transmission the header added will be there and can > be

Re: SKB Reference Question

On Wed, 2017-11-01 at 12:22 -0700, Joe Smith wrote: > On Wed, Nov 1, 2017 at 10:33 AM, Eric Dumazet wrote: > > On Wed, 2017-11-01 at 10:27 -0700, Joe Smith wrote: > >> How strictly are references on the SKB enforced. For example, > >> tcp_transmit_skb() clones the SKB and

Re: SKB Reference Question

On Wed, Nov 1, 2017 at 10:33 AM, Eric Dumazet wrote: > On Wed, 2017-11-01 at 10:27 -0700, Joe Smith wrote: >> How strictly are references on the SKB enforced. For example, >> tcp_transmit_skb() clones the SKB and adds a TCP header. Can I assume >> that in case of

Re: SKB Reference Question

On Wed, 2017-11-01 at 10:27 -0700, Joe Smith wrote: > How strictly are references on the SKB enforced. For example, > tcp_transmit_skb() clones the SKB and adds a TCP header. Can I assume > that in case of re-transmission the header added will be there and can > be reused instead of creating a new

SKB Reference Question

How strictly are references on the SKB enforced. For example, tcp_transmit_skb() clones the SKB and adds a TCP header. Can I assume that in case of re-transmission the header added will be there and can be reused instead of creating a new one from scratch. Some fields like time stamp would need to

Re: intel i40e buggy driver question

; 1) { > num = (mss == 0) ? 0 : 1; > mss += mp->m_pkthdr.tso_segsz; > } > > Intel FreeBSD Team: This will definitely prevent MDDs on the buffers you > sent me. > > " > > > An I have a question - how to d

Re: intel i40e buggy driver question

   if (num > IXL_SPARSE_CHAIN)     return (true);     if (mss < 1) {     num = (mss == 0) ? 0 : 1;     mss += mp->m_pkthdr.tso_segsz;     } Intel FreeBSD Team: This will definitely prevent MDDs on the buffers you sent me. &

intel i40e buggy driver question

return (true);     if (mss < 1) {     num = (mss == 0) ? 0 : 1;     mss += mp->m_pkthdr.tso_segsz;     } Intel FreeBSD Team: This will definitely prevent MDDs on the buffers you sent me. " An I have a question - how to do the same in l

Re: [QUESTION] poor TX performance on new GbE driver

ts from the box to my AMD >> Seattle based devbox with a 1 Gbit switch in between. (The NIC in >> question is also 1 Gbit) >> >> >> $ sudo iperf -c dogfood.local -r >> --

Re: [QUESTION] poor TX performance on new GbE driver

> 17.04 rootfs works absolutely fine. Note that this is using the exact > same kernel image, booted off the network. > > Under Ubuntu, I get the following iperf results from the box to my AMD > Seattle based devbox with a 1 Gbit switch in between. (The NIC in > question is als

Re: [QUESTION] poor TX performance on new GbE driver

the box to my AMD >> Seattle based devbox with a 1 Gbit switch in between. (The NIC in >> question is also 1 Gbit) >> >> >> $ sudo iperf -c dogfood.local -r >> --

Re: [QUESTION] poor TX performance on new GbE driver

17.04 rootfs works absolutely fine. Note that this is using the exact > same kernel image, booted off the network. > > Under Ubuntu, I get the following iperf results from the box to my AMD > Seattle based devbox with a 1 Gbit switch in between. (The NIC in > question is also 1 Gbit) >

[QUESTION] poor TX performance on new GbE driver

image, booted off the network. Under Ubuntu, I get the following iperf results from the box to my AMD Seattle based devbox with a 1 Gbit switch in between. (The NIC in question is also 1 Gbit) $ sudo iperf -c dogfood.local -r Server

Re: Ethtool question

On 16-Oct-17 21:10, Ben Greear wrote: > On 10/12/2017 03:00 PM, Roopa Prabhu wrote: >> On Thu, Oct 12, 2017 at 2:45 PM, Ben Greear wrote: >>> On 10/11/2017 01:49 PM, David Miller wrote: From: "John W. Linville" Date: Wed, 11 Oct

Re: Ethtool question

On 10/12/2017 03:00 PM, Roopa Prabhu wrote: On Thu, Oct 12, 2017 at 2:45 PM, Ben Greear wrote: On 10/11/2017 01:49 PM, David Miller wrote: From: "John W. Linville" Date: Wed, 11 Oct 2017 16:44:07 -0400 On Wed, Oct 11, 2017 at 09:51:56AM

Re: Ethtool question

On Thu, Oct 12, 2017 at 2:45 PM, Ben Greear wrote: > On 10/11/2017 01:49 PM, David Miller wrote: >> >> From: "John W. Linville" >> Date: Wed, 11 Oct 2017 16:44:07 -0400 >> >>> On Wed, Oct 11, 2017 at 09:51:56AM -0700, Ben Greear wrote: I

Re: Ethtool question

On 10/11/2017 01:49 PM, David Miller wrote: From: "John W. Linville" Date: Wed, 11 Oct 2017 16:44:07 -0400 On Wed, Oct 11, 2017 at 09:51:56AM -0700, Ben Greear wrote: I noticed today that setting some ethtool settings to the same value returns an error code. I would

Re: Ethtool question

From: "John W. Linville" Date: Wed, 11 Oct 2017 16:44:07 -0400 > On Wed, Oct 11, 2017 at 09:51:56AM -0700, Ben Greear wrote: >> I noticed today that setting some ethtool settings to the same value >> returns an error code. I would think this should silently return >>

Re: Ethtool question

On Wed, Oct 11, 2017 at 09:51:56AM -0700, Ben Greear wrote: > I noticed today that setting some ethtool settings to the same value > returns an error code. I would think this should silently return > success instead? Makes it easier to call it from scripts this way: > > [root@lf0313-6477

Ethtool question

I noticed today that setting some ethtool settings to the same value returns an error code. I would think this should silently return success instead? Makes it easier to call it from scripts this way: [root@lf0313-6477 lanforge]# ethtool -L eth3 combined 1 combined unmodified, ignoring no

Question about "prevent dst uses after free" and WARNING in nf_xfrm_me_harder / refcnt / 4.13.3

Hi, I'm running now 4.13.3, is this patch required for 4.13 as well? (it doesnt apply cleanly, as in 4.13 tcp_prequeue use skb_dst_force_safe, so i just renamed it there to skb_dst_force ) This is what i get on PPPoE BRAS on this kernel, patch applied (no idea if its related to patch, but

  1   2   3   4   5   6   7   >