gmane.linux.network

Re: TCPBacklogDrops during aggressive bursts of traffic

Eric Dumazet — 2012-05-23T12:09:38



Here is the patch for ixgbe, for reference.

My machine is now able to receive a netperf TCP_STREAM full speed
(10Gb), even with GRO/LRO off. (TCPRcvCoalesce counter increasing very
fast too)

Its not an official patch yet, because :

1) I need to properly align DMA buffers to reserve NET_SKB_PAD bytes
(not all workloads are like TCP, and some headroom is needed for
tunnels)

2) Must cope with MTU > 1500 cases

3) Should not be done if NET_IP_ALIGN is not null (I dont know if ixgbe
hardware can do the DMA to non aligned area on receive)

This patch saves 1024 bytes per incoming skb. (skb->head directly mapped
to the frag containing the frame, instead of a separate memory area)

 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |   82 ++++++++--------
 1 file changed, 46 insertions(+), 36 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index bf20457..d05693a 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/eth

Re: [PATCH v3 00/17] netfilter: add namespace support for netfilter protos

Pablo Neira Ayuso — 2012-05-23T10:42:31

This requires another spin. It looks way better than previous version
but I don't want to take the patchset and then send another batch to
David to remove the .compat field, the unrequired export of couple of
symbols, and so on...

Thanks!

Re: [PATCH 15/17] netfilter: cleanup sysctl for l4proto and l3proto

Pablo Neira Ayuso — 2012-05-23T10:38:10

Interesting. This structure is added in patch 1/17, then it's remove
in patch 15/17.

Probably I'm missing anything, but why are you doing it like that?

Re: [V2 PATCH 9/9] vhost: zerocopy: poll vq in zerocopy callback

Jason Wang — 2012-05-23T10:31:36

Didn't think this can work well as the notification from guest were 
disabled forever.

Re: [PATCH 03/17] netfilter: add namespace support for l3proto

Pablo Neira Ayuso — 2012-05-23T10:29:10

                                ^^^^^
please, rename this to something like nf_ct_proto.


Under what circunstances that in be NULL?


do we need this extra NULL assignment?


Same things as in previous patch. Move...

if (net == &init_net) {
     ... this code ...
}

into some static int nf_conntrack_l3proto_register_net function.


Same thing as above.

Re: TCPBacklogDrops during aggressive bursts of traffic

Eric Dumazet — 2012-05-23T09:44:06

Update :

My tests show that sk_backlog.len can reach 1.5MB easily on a netperf,
even with a fast machine, receiving a 10Gb flow (ixgbe adapter), if
LRO/GRO are off.

424 backlogdrop for 193.182.546 incoming packets (with my tcp_space()
patch applied)

I believe that as soon as ixgbe can use build_skb() and avoid the 1024
bytes overhead per skb, it should go away.

Of course, another way to solve the problem would be to change
tcp_recvmsg() to use lock_sock_fast(), so that no frame is backlogged at
all.

Locking the socket for the whole operation (including copyout to user)
is not very good. It was good enough years ago with small receive
window.

With a potentially huge backlog, it means user process has to process
it, regardless of its latency constraints. CPU caches are also
completely destroyed because of huge amount of data included in thousand
of skbs.

Re: [PATCH 1/3] drivers: net: stmmac: add blackfin support

Giuseppe CAVALLARO — 2012-05-23T08:27:05

 platform fields to use are: tx_coe and rx_coe.

Peppe

Re: [PATCH 1/3] drivers: net: stmmac: add blackfin support

Giuseppe CAVALLARO — 2012-05-23T08:21:29

Hello Bob Liu

On 5/23/2012 9:58 AM, Bob Liu wrote:

Hmm this should be debugged ... maybe you can verify the tx / rx
checksum. I mean if your IP has these modules or if, for somereason, the
HW cap register is not present and there are not properly fixed


With your patch (that added the dwmac1000 into the dwmac100) you are
indeed using the MAC100 setting where by default there is no HW
checksumming ;-)


you are welcome

Peppe

Kernel doesn't propagate DNSSL to userspace (e.g. NetworkManager)

Pavel Simerda — 2012-05-23T08:16:17

Hi,

I filed a bugreport to about lack of DNSSL support in kernel:

https://bugzilla.redhat.com/show_bug.cgi?id=824121

While NetworkManager recieves RDNSS neighbor discovery user option from kernel, it doesn't recieve DNSSL at all. This can be debugged with NetworkManager
(or hopefully some better testing tool) and radvdump (to check if DNSSL is present).

radvdump reports DNSSL is there, NetworkManager gets no netlink message from kernel.

kernel-3.3.4-4.fc17.x86_64
NetworkManager-0.9.4.0-7.git20120403.fc17.x86_64

Dave Jones asked me to contact this ML directly. I'm offlist.

Cheers,

Pavel Šimerda

Re: [PATCH 1/3] drivers: net: stmmac: add blackfin support

Bob Liu — 2012-05-23T07:58:13

Hi Peppe,

On 5/22/12, Giuseppe CAVALLARO <peppe.cavallaro< at >st.com> wrote:

Thank you for your reply.
I tried to use driver dwmac1000 by setting .has_gmac = 1 today.
Ping can finish with no error but when rcp a file or telnet it will hang.

Using below patch without setting .has_gmac, everything works fine.
Any ideas?  Thank you.

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100.h
b/drivers/net/ethernet/stmicro/stmmac/dwmac100.h
index 7c6d857..00499b8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac100.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100.h
< at >< at > -29,6 +29,18 < at >< at >
  *                             MAC BLOCK defines
  *---------------------------------------------------------------------------*/
 /* MAC CSR offset */
+#if defined(CONFIG_BLACKFIN)
+#define MAC_CONTROL    0x00000000      /* MAC Control */
+#define MAC_FRAME_FILTER       0x0000004       /* Frame filter */
+#define MAC_HASH_HIGH  0x00000008      /* Multicast Hash Table High */
+#define MAC_HASH_LOW   0x0000000c      /* Mult

Re: [PATCH 1/4] stmmac: remove two useless initialisation

Giuseppe CAVALLARO — 2012-05-23T07:38:02

Previous ones were for net-next and in fact in the subject I indeed used:

  [net-next X/N] stmmac: ....

After your comment I re-sent them for net.git (pls see my previous email
where I clarified that).

I have always posted all my patches for net-next adding its suffix in
the subject.

For all the patches for net.git I've never added the suffix but I'll do
that.

I agree with you that the suffix should be added and I had understood
(and always used and fixed in my subjectprefix) that these were the
format of the patches in this mailing list

[PATCH] ...        =>>> for net.git
[PATCH net-next]   =>>> for net-next.git

So I'll use starting from now:

[PATCH (net.git)]    =>>> for net.git
[PATCH (net-next)]   =>>> for net-next.git

Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow

Yanmin Zhang — 2012-05-23T07:24:22

We would do so in a new patch.

David suggests to reset it to NULL to detect other potential
race conditions.

Besides above suggestions, how do you think about:

fib_create_info=>fib_find_info, but fib_find_info is not protected by
fib_info_lock. See the codes:

fib_create_info()
{
...
link_it:
        ofi = fib_find_info(fi);
        if (ofi) {
                fi->fib_dead = 1;
                free_fib_info(fi);
                ofi->fib_treeref++;
                return ofi;
        }
        fi->fib_treeref++;
        atomic_inc(&fi->fib_clntref);
        spin_lock_bh(&fib_info_lock);

...
}

I plan to change it to hold fib_info_lock before calling fib_find_info. Is
it ok for you?

Thanks for the direct speaking.

Yanmin

Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow

Eric Dumazet — 2012-05-23T06:43:33


This part might need additional fix (if FIB_RES_DEV(*res) is NULL),
because __in_dev_get_rcu() could crash dereferencing NULL pointer.

Re: [PATCH 1/4] stmmac: remove two useless initialisation

David Miller — 2012-05-23T06:42:11

You really need to post your patches properly.

In particular, you need to indicate, either in an initial "[PATCH 0/N]"
posting, or in the subject lines of that patch, exactly what tree
you are targetting.

And if this is meant for net-next, I told you specifically that net-next
is not open right now and you need to submit this later when I make
the announcement here that it is open.

We are in the middle of the merge window, and therefore you should only
be submitting bug fixes against the 'net' tree.

It is extremely irritating that, when I go out of my way to make
announcements here on this list, multiple times, about what kind of
patches are appropriate and what kinds are not, and yet people still
do not listen and they still submit any old crap they feel like
submitting.

People need to stop this, now.

Pay attention to the development state, and follow the rules,
otherwise you'll royally piss me off and I'll ignore your patches
completely.

Thanks.

[PATCH 4/4] stmmac: update driver's doc

Giuseppe CAVALLARO — 2012-05-23T06:36:04

Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro< at >st.com>
---
 Documentation/networking/stmmac.txt |   44 +++++++++++++++++++---------------
 1 files changed, 25 insertions(+), 19 deletions(-)

diff --git a/Documentation/networking/stmmac.txt b/Documentation/networking/stmmac.txt
index ab1e8d7..5cb9a19 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
< at >< at > -10,8 +10,8 < at >< at > Currently this network device driver is for all STM embedded MAC/GMAC
 (i.e. 7xxx/5xxx SoCs), SPEAr (arm), Loongson1B (mips) and XLINX XC2V3000
 FF1152AMT0221 D1215994A VIRTEX FPGA board.
 
-DWC Ether MAC 10/100/1000 Universal version 3.60a (and older) and DWC Ether MAC 10/100
-Universal version 4.0 have been used for developing this driver.
+DWC Ether MAC 10/100/1000 Universal version 3.60a (and older) and DWC Ether
+MAC 10/100 Universal version 4.0 have been used for developing this driver.
 
 This driver supports both the platform bus and PCI.
 
< at >< at > -54,27 +54,27 < at >< at > net_device structure enabling the

[PATCH 2/4] stmmac: fix driver's doc when run kernel-doc script

Giuseppe CAVALLARO — 2012-05-23T06:36:02

Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro< at >st.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 0caae72..18ed878 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
< at >< at > -833,8 +833,9 < at >< at > static u32 stmmac_get_synopsys_id(struct stmmac_priv *priv)
 
 /**
  * stmmac_selec_desc_mode
- * < at >dev : device pointer
- * Description: select the Enhanced/Alternate or Normal descriptors */
+ * < at >priv : private structure
+ * Description: select the Enhanced/Alternate or Normal descriptors
+ */
 static void stmmac_selec_desc_mode(struct stmmac_priv *priv)
 {
 if (priv->plat->enh_desc) {
< at >< at > -1860,6 +1861,8 < at >< at > static int stmmac_hw_init(struct stmmac_priv *priv)
 /**
  * stmmac_dvr_probe
  * < at >device: device pointer
+ * < at >plat_dat: platform data pointer
+ * < at >addr:

[PATCH 3/4] stmmac: fix driver Kconfig when built as module

Giuseppe CAVALLARO — 2012-05-23T06:36:03

This patches fixes the driver when built as dyn module.
In fact the platform part cannot be built and the probe fails
(thanks to Bob Liu that reported this bug).
The patch also makes the selection of Platform and PCI parts
mutually exclusive.

Reported-by: Bob Liu <lliubbo< at >gmail.com>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro< at >st.com>
Reviewed-by: Ben Hutchings <bhutchings< at >solarflare.com>
cc: Rayagond Kokatanur <rayagond< at >vayavyalabs.com>
---
 drivers/net/ethernet/stmicro/stmmac/Kconfig |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 0364283..3318b32 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
< at >< at > -12,10 +12,12 < at >< at > config STMMAC_ETH
 
 if STMMAC_ETH
 
+choice
+        prompt "STMMAC bus support"
+
 config STMMAC_PLATFORM
-tristate "STMMAC platform bus support"
+bool "Platform bus support"
 depends on STMMAC_ETH
-

[PATCH 1/4] stmmac: remove two useless initialisation

Giuseppe CAVALLARO — 2012-05-23T06:36:01

This patch removes two useful initialisation in the
stmmac_rx and stmmac_tx function.
In the former, count var was already reset and in the
stmmac_tx we only need to increment the dirty pointer
w/o setting the entry var.

Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro< at >st.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 7096633..0caae72 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
< at >< at > -677,7 +677,7 < at >< at > static void stmmac_tx(struct stmmac_priv *priv)
 
 priv->hw->desc->release_tx_desc(p);
 
-entry = (++priv->dirty_tx) % txsize;
+priv->dirty_tx++;
 }
 if (unlikely(netif_queue_stopped(priv->dev) &&
      stmmac_tx_avail(priv) > STMMAC_TX_THRESH(priv))) {
< at >< at > -1307,7 +1307,6 < at >< at > static int stmmac_rx(struct stmmac_priv *priv, int limit)
 d

Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow

Eric Dumazet — 2012-05-23T06:27:39


No, its not needed.

I am sending a patch, because I feel this area is too complex for non
netdev guys.

Re: [net-next 1/4] stmmac: modify and improve the bus_setup platform callback

Giuseppe CAVALLARO — 2012-05-23T06:19:02

Hello David

On 5/23/2012 7:43 AM, David Miller wrote:

Ok, so only these patches shouldbe considered:

  stmmac: update driver's doc
  stmmac: remove two useless initialisation
  stmmac: remove two useless initialisation

and

  stmmac: fix driver Kconfig when built as module
     This is attached to another thread and under review.



Thanks, I'm resending them again for net.git.


I'll only resend the following patch (that should be stay in next repo)
later:
     stmmac: modify and improve the bus_setup platform callback

Regards
Peppe

Re: [PATCH] rfkill: Add handling when rfkill's type is RFKILL_TYPE_ALL.

Alex Hung — 2012-05-23T06:12:41

Thanks for your feedback, I re-wrote the comments to clarify the changes 
and re-submitted.

Cheers,
Alex Hung