* [PATCH 4/5] pktgen: enable automatic IPv6 address setting
From: Cong Wang @ 2012-10-09 10:05 UTC (permalink / raw)
To: netdev; +Cc: Cong Wang, David S. Miller
In-Reply-To: <1349777131-4425-1-git-send-email-amwang@redhat.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
net/core/pktgen.c | 18 +++++-------------
1 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index a6acd49..9797f26 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -2037,6 +2037,9 @@ static void pktgen_setup_inject(struct pktgen_dev *pkt_dev)
memcpy(&(pkt_dev->hh[0]), pkt_dev->dst_mac, ETH_ALEN);
if (pkt_dev->flags & F_IPV6) {
+ int i, set = 0, err = 1;
+ struct inet6_dev *idev;
+
if (pkt_dev->min_pkt_size == 0) {
pkt_dev->min_pkt_size = 14 + sizeof(struct ipv6hdr)
+ sizeof(struct udphdr)
@@ -2046,15 +2049,6 @@ static void pktgen_setup_inject(struct pktgen_dev *pkt_dev)
pkt_dev->cur_pkt_size = pkt_dev->min_pkt_size;
- /*
- * Skip this automatic address setting until locks or functions
- * gets exported
- */
-
-#ifdef NOTNOW
- int i, set = 0, err = 1;
- struct inet6_dev *idev;
-
for (i = 0; i < IN6_ADDR_HSIZE; i++)
if (pkt_dev->cur_in6_saddr.s6_addr[i]) {
set = 1;
@@ -2075,9 +2069,8 @@ static void pktgen_setup_inject(struct pktgen_dev *pkt_dev)
struct inet6_ifaddr *ifp;
read_lock_bh(&idev->lock);
- for (ifp = idev->addr_list; ifp;
- ifp = ifp->if_next) {
- if (ifp->scope == IFA_LINK &&
+ list_for_each_entry(ifp, &idev->addr_list, if_list) {
+ if ((ifp->scope & IFA_LINK) &&
!(ifp->flags & IFA_F_TENTATIVE)) {
pkt_dev->cur_in6_saddr = ifp->addr;
err = 0;
@@ -2090,7 +2083,6 @@ static void pktgen_setup_inject(struct pktgen_dev *pkt_dev)
if (err)
pr_err("ERROR: IPv6 link address not available\n");
}
-#endif
} else {
if (pkt_dev->min_pkt_size == 0) {
pkt_dev->min_pkt_size = 14 + sizeof(struct iphdr)
--
1.7.7.6
^ permalink raw reply related
* [PATCH 5/5] pktgen: replace scan_ip6() with in6_pton()
From: Cong Wang @ 2012-10-09 10:05 UTC (permalink / raw)
To: netdev; +Cc: Cong Wang, David S. Miller
In-Reply-To: <1349777131-4425-1-git-send-email-amwang@redhat.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
net/core/pktgen.c | 101 ++--------------------------------------------------
1 files changed, 4 insertions(+), 97 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 9797f26..a34cff3 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -449,8 +449,6 @@ static void pktgen_stop_all_threads_ifs(void);
static void pktgen_stop(struct pktgen_thread *t);
static void pktgen_clear_counters(struct pktgen_dev *pkt_dev);
-static unsigned int scan_ip6(const char *s, char ip[16]);
-
/* Module parameters, defaults. */
static int pg_count_d __read_mostly = 1000;
static int pg_delay_d __read_mostly;
@@ -1299,7 +1297,7 @@ static ssize_t pktgen_if_write(struct file *file,
return -EFAULT;
buf[len] = 0;
- scan_ip6(buf, pkt_dev->in6_daddr.s6_addr);
+ in6_pton(buf, -1, pkt_dev->in6_daddr.s6_addr, -1, NULL);
snprintf(buf, sizeof(buf), "%pI6c", &pkt_dev->in6_daddr);
pkt_dev->cur_in6_daddr = pkt_dev->in6_daddr;
@@ -1322,7 +1320,7 @@ static ssize_t pktgen_if_write(struct file *file,
return -EFAULT;
buf[len] = 0;
- scan_ip6(buf, pkt_dev->min_in6_daddr.s6_addr);
+ in6_pton(buf, -1, pkt_dev->min_in6_daddr.s6_addr, -1, NULL);
snprintf(buf, sizeof(buf), "%pI6c", &pkt_dev->min_in6_daddr);
pkt_dev->cur_in6_daddr = pkt_dev->min_in6_daddr;
@@ -1344,7 +1342,7 @@ static ssize_t pktgen_if_write(struct file *file,
return -EFAULT;
buf[len] = 0;
- scan_ip6(buf, pkt_dev->max_in6_daddr.s6_addr);
+ in6_pton(buf, -1, pkt_dev->max_in6_daddr.s6_addr, -1, NULL);
snprintf(buf, sizeof(buf), "%pI6c", &pkt_dev->max_in6_daddr);
if (debug)
@@ -1365,7 +1363,7 @@ static ssize_t pktgen_if_write(struct file *file,
return -EFAULT;
buf[len] = 0;
- scan_ip6(buf, pkt_dev->in6_saddr.s6_addr);
+ in6_pton(buf, -1, pkt_dev->in6_saddr.s6_addr, -1, NULL);
snprintf(buf, sizeof(buf), "%pI6c", &pkt_dev->in6_saddr);
pkt_dev->cur_in6_saddr = pkt_dev->in6_saddr;
@@ -2764,97 +2762,6 @@ static struct sk_buff *fill_packet_ipv4(struct net_device *odev,
return skb;
}
-/*
- * scan_ip6, fmt_ip taken from dietlibc-0.21
- * Author Felix von Leitner <felix-dietlibc@fefe.de>
- *
- * Slightly modified for kernel.
- * Should be candidate for net/ipv4/utils.c
- * --ro
- */
-
-static unsigned int scan_ip6(const char *s, char ip[16])
-{
- unsigned int i;
- unsigned int len = 0;
- unsigned long u;
- char suffix[16];
- unsigned int prefixlen = 0;
- unsigned int suffixlen = 0;
- __be32 tmp;
- char *pos;
-
- for (i = 0; i < 16; i++)
- ip[i] = 0;
-
- for (;;) {
- if (*s == ':') {
- len++;
- if (s[1] == ':') { /* Found "::", skip to part 2 */
- s += 2;
- len++;
- break;
- }
- s++;
- }
-
- u = simple_strtoul(s, &pos, 16);
- i = pos - s;
- if (!i)
- return 0;
- if (prefixlen == 12 && s[i] == '.') {
-
- /* the last 4 bytes may be written as IPv4 address */
-
- tmp = in_aton(s);
- memcpy((struct in_addr *)(ip + 12), &tmp, sizeof(tmp));
- return i + len;
- }
- ip[prefixlen++] = (u >> 8);
- ip[prefixlen++] = (u & 255);
- s += i;
- len += i;
- if (prefixlen == 16)
- return len;
- }
-
-/* part 2, after "::" */
- for (;;) {
- if (*s == ':') {
- if (suffixlen == 0)
- break;
- s++;
- len++;
- } else if (suffixlen != 0)
- break;
-
- u = simple_strtol(s, &pos, 16);
- i = pos - s;
- if (!i) {
- if (*s)
- len--;
- break;
- }
- if (suffixlen + prefixlen <= 12 && s[i] == '.') {
- tmp = in_aton(s);
- memcpy((struct in_addr *)(suffix + suffixlen), &tmp,
- sizeof(tmp));
- suffixlen += 4;
- len += strlen(s);
- break;
- }
- suffix[suffixlen++] = (u >> 8);
- suffix[suffixlen++] = (u & 255);
- s += i;
- len += i;
- if (prefixlen + suffixlen == 16)
- break;
- }
- for (i = 0; i < suffixlen; i++)
- ip[16 - suffixlen + i] = suffix[i];
- return len;
-}
-
static struct sk_buff *fill_packet_ipv6(struct net_device *odev,
struct pktgen_dev *pkt_dev)
{
--
1.7.7.6
^ permalink raw reply related
* [net 0/3][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2012-10-09 10:13 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann
This series contains updates to ixgbe, ixgbevf and e1000e.
The following are changes since commit 66eef59f22275002f621ff9d951886b513d011b3:
net: fix typo in freescale/ucc_geth.c
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net master
Alexander Duyck (1):
ixgbe/ixgbevf: Limit maximum jumbo frame size to 9.5K to avoid Tx
hangs
Bruce Allan (1):
e1000e: add device IDs for i218
Greg Rose (1):
ixgbevf: Set the netdev number of Tx queues
drivers/net/ethernet/intel/e1000e/hw.h | 2 ++
drivers/net/ethernet/intel/e1000e/netdev.c | 2 ++
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 2 +-
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 2 +-
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 7 +++++++
5 files changed, 13 insertions(+), 2 deletions(-)
--
1.7.11.4
^ permalink raw reply
* [net 1/3] ixgbevf: Set the netdev number of Tx queues
From: Jeff Kirsher @ 2012-10-09 10:13 UTC (permalink / raw)
To: davem; +Cc: Greg Rose, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1349777612-30149-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Greg Rose <gregory.v.rose@intel.com>
The driver was not setting the number of real Tx queues in the net_device
structure. This caused some serious issues such as Tx hangs and extremely
poor performance with some usages of the driver.
The issue is best observed by running:
iperf -c <host> -P <n>
Where n is greater than one. The greater the value of n the more likely
the problem is to show up.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 0ee9bd4..de1ad50 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -1747,6 +1747,7 @@ err_tx_ring_allocation:
**/
static int ixgbevf_set_interrupt_capability(struct ixgbevf_adapter *adapter)
{
+ struct net_device *netdev = adapter->netdev;
int err = 0;
int vector, v_budget;
@@ -1775,6 +1776,12 @@ static int ixgbevf_set_interrupt_capability(struct ixgbevf_adapter *adapter)
ixgbevf_acquire_msix_vectors(adapter, v_budget);
+ err = netif_set_real_num_tx_queues(netdev, adapter->num_tx_queues);
+ if (err)
+ goto out;
+
+ err = netif_set_real_num_rx_queues(netdev, adapter->num_rx_queues);
+
out:
return err;
}
--
1.7.11.4
^ permalink raw reply related
* [net 2/3] ixgbe/ixgbevf: Limit maximum jumbo frame size to 9.5K to avoid Tx hangs
From: Jeff Kirsher @ 2012-10-09 10:13 UTC (permalink / raw)
To: davem; +Cc: Alexander Duyck, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1349777612-30149-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
This change limits the PF/VF driver to 9.5K max jumbo frame size in order
prevent a possible Tx hang in the adapter when sending frames between
pools.
All of the parts in ixgbe support a maximum frame of 15.5K for standard
traffic, however with SR-IOV or DCB enabled they should be limiting the
MTU size to 9.5K. Instead of adding extra checks which would have to
change the MTU when we go into or out of these modes it is preferred to
just use a standard 9.5K MTU limit for all modes so that this extra
overhead can be avoided.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 2 +-
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index 5bd2676..30efc9f 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -410,7 +410,7 @@ static inline u16 ixgbe_desc_unused(struct ixgbe_ring *ring)
#define IXGBE_TX_CTXTDESC(R, i) \
(&(((struct ixgbe_adv_tx_context_desc *)((R)->desc))[i]))
-#define IXGBE_MAX_JUMBO_FRAME_SIZE 16128
+#define IXGBE_MAX_JUMBO_FRAME_SIZE 9728 /* Maximum Supported Size 9.5KB */
#ifdef IXGBE_FCOE
/* Use 3K as the baby jumbo frame size for FCoE */
#define IXGBE_FCOE_JUMBO_FRAME_SIZE 3072
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
index 383b4e1..4a9c9c2 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
@@ -175,7 +175,7 @@ struct ixgbevf_q_vector {
#define IXGBEVF_TX_CTXTDESC(R, i) \
(&(((struct ixgbe_adv_tx_context_desc *)((R)->desc))[i]))
-#define IXGBE_MAX_JUMBO_FRAME_SIZE 16128
+#define IXGBE_MAX_JUMBO_FRAME_SIZE 9728 /* Maximum Supported Size 9.5KB */
#define OTHER_VECTOR 1
#define NON_Q_VECTORS (OTHER_VECTOR)
--
1.7.11.4
^ permalink raw reply related
* [net 3/3] e1000e: add device IDs for i218
From: Jeff Kirsher @ 2012-10-09 10:13 UTC (permalink / raw)
To: davem; +Cc: Bruce Allan, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1349777612-30149-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Bruce Allan <bruce.w.allan@intel.com>
i218 is the next-generation LOM that will be available on systems with the
Lynx Point LP Platform Controller Hub (PCH) chipset from Intel. This patch
provides the initial support of those devices.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/e1000e/hw.h | 2 ++
drivers/net/ethernet/intel/e1000e/netdev.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/intel/e1000e/hw.h b/drivers/net/ethernet/intel/e1000e/hw.h
index ed5b409..d37bfd9 100644
--- a/drivers/net/ethernet/intel/e1000e/hw.h
+++ b/drivers/net/ethernet/intel/e1000e/hw.h
@@ -412,6 +412,8 @@ enum e1e_registers {
#define E1000_DEV_ID_PCH2_LV_V 0x1503
#define E1000_DEV_ID_PCH_LPT_I217_LM 0x153A
#define E1000_DEV_ID_PCH_LPT_I217_V 0x153B
+#define E1000_DEV_ID_PCH_LPTLP_I218_LM 0x155A
+#define E1000_DEV_ID_PCH_LPTLP_I218_V 0x1559
#define E1000_REVISION_4 4
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index fb659dd..de57a2b 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6558,6 +6558,8 @@ static DEFINE_PCI_DEVICE_TABLE(e1000_pci_tbl) = {
{ PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_LPT_I217_LM), board_pch_lpt },
{ PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_LPT_I217_V), board_pch_lpt },
+ { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_LPTLP_I218_LM), board_pch_lpt },
+ { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_LPTLP_I218_V), board_pch_lpt },
{ 0, 0, 0, 0, 0, 0, 0 } /* terminate list */
};
--
1.7.11.4
^ permalink raw reply related
* SMSC LAN9512 PowerPC Linux Driver Problem
From: José Alexandre Ventura @ 2012-10-09 11:01 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: Aníbal Almeida Pinto, José Alexandre Ventura
Hi,
I'm having problems with an SMSC EVB9512, based on the LAN9512 chip, when using with a PowerPC Chip. The Driver I'm using is the one already provided by Linux.
I have tested the EVB9512 in two test configurations, both using a PowerPC:
First Test Configuration:
- Custom Board with PowerPC Fresscale MPC8378 @ 667MHz
- Linux Kernel 3.0.0
- EVB9512 connected via USB
Problems with First Test Configuration:
- nmap reports ports has filtered, even thought they are open
- can't establish any connection, even a TCP socket
- can ping the Board with other Devices without a problem
I have made more tests and found out that even though I can receive and send packages, my TX packages had incorrect TCP checksum.
I then used ethtool to disable TX Checksum offloading and all my problems were solved. The problem with this 'fix' is that it uses more CPU and when under heavy load, I get an error and the ethernet port is shut.
Second Configuration:
- PowerBook G4 1.5GHz, 1.25MB DDR333
- Ubuntu Live CD 12.04 LTS
- EVB9512 connected via USB
Problems with second Configuration:
- TX packets appears as errors in ifconfig
- The powerbook is pinged from another machine without a problem but the PowerBook can't ping the other device
I have also tested the EVB9512 with a Custom Card with an OMAP L138 and also tested with a Toshiba Notebook with an Intel Core i5, both without any problems. This shows that it is not a problem with the EVB9512 itself because it works correctly with other architectures. I think the problems lies in the PowerPC driver of the LAN95xx.
Best Regards,
José Ventura
^ permalink raw reply
* RE: [PATCH] flexcan: disable bus error interrupts for the i.MX28
From: Dong Aisheng-B29396 @ 2012-10-09 11:52 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Wolfgang Grandegger, Shawn Guo, Linux Netdev List, Linux-CAN,
Hui Wang
In-Reply-To: <50729D73.3050409@pengutronix.de>
Hi Wolfgang,
>-----Original Message-----
>From: Dong Aisheng-B29396
>Sent: Monday, October 08, 2012 5:44 PM
>To: 'Marc Kleine-Budde'
>Cc: Wolfgang Grandegger; Shawn Guo; Linux Netdev List; Linux-CAN; Hui Wang
>Subject: RE: [PATCH] flexcan: disable bus error interrupts for the i.MX28
>
>>-----Original Message-----
>>From: Marc Kleine-Budde [mailto:mkl@pengutronix.de]
>>Sent: Monday, October 08, 2012 5:32 PM
>>To: Dong Aisheng-B29396
>>Cc: Wolfgang Grandegger; Shawn Guo; Linux Netdev List; Linux-CAN; Hui
>>Wang
>>Subject: Re: [PATCH] flexcan: disable bus error interrupts for the
>>i.MX28
>>Importance: High
>>
>>On 10/08/2012 11:13 AM, Dong Aisheng-B29396 wrote:
>>>>> I just checked our ic guy of flexcan, it seems he also had no sense
>>>>> of
>>>> this issue.
>>>>>
>>>>> Below is some version info what I got:
>>>>> Mx6s use FlexCAN3, with IP version 10.00.12.00
>>>>> Mx53 use FlexCAN2 (with glitch filter), with IP version 03.00.00.00
>>>>> Mx28 use FlexCAN2 (with glitch filter), with IP version 03.00.04.00
>>>>> Mx35 use FlexCAN2 (without glitch filter) , with IP version
>>>>> 03.00.00.00
>>>>> Mx25 use FlexCAN2 (without glitch filter), with IP version
>>>>> 03.00.00.00 I'm not sure if mx6q has such issue.
>>>>
>>>> OK, we need to find that out experimentally.
>>>>
>>> Our IC owner double checked the MX35 and MX53 IP and found the
>>> RX_WARN & TX_WARN Interrupt source actually are not connected to ARM.
>>
>>Does this mean it's a SoC problem, not a problem of the ip core?
>>
>It's not a problem of ip core, it's about how to use the IP.
>I do not know why some i.MX SoCs does not use rx/tx warn interrupts.
>
>>> That means flexcan will not trigger interrupt to ARM core even
>>> RX_WARN or TX_WARN Happens.
>>> This may be the root cause that why you cannot see RX_WARN interrupt
>>> if not enable bus error interrupt on mx35.
>>> He also checked that mx6q has the rx/tx warning interrupt connected
>>> to
>>arm.
>>> So we guess mx6q does not have this issue.
>>> Anyway, we can test to confirm.
>>
>>What about mx25?
>>
>For mx25 and mx28, he could not access it now.
>Will check tomorrow.
>
Just let you know:
The checking result is Mx28 has rx/tx warning interrupt line connected
while mx25 not.
Looks align with what we guess.
Regards
Dong Aisheng
^ permalink raw reply
* Re: [PATCH] flexcan: disable bus error interrupts for the i.MX28
From: Wolfgang Grandegger @ 2012-10-09 12:32 UTC (permalink / raw)
To: Dong Aisheng-B29396
Cc: Marc Kleine-Budde, Shawn Guo, Linux Netdev List, Linux-CAN,
Hui Wang
In-Reply-To: <7FE21149F4667147B645348EC60578850B36E998@039-SN2MPN1-011.039d.mgd.msft.net>
On 10/09/2012 01:52 PM, Dong Aisheng-B29396 wrote:
> Hi Wolfgang,
>
>> -----Original Message-----
>> From: Dong Aisheng-B29396
>> Sent: Monday, October 08, 2012 5:44 PM
>> To: 'Marc Kleine-Budde'
>> Cc: Wolfgang Grandegger; Shawn Guo; Linux Netdev List; Linux-CAN; Hui Wang
>> Subject: RE: [PATCH] flexcan: disable bus error interrupts for the i.MX28
>>
>>> -----Original Message-----
>>> From: Marc Kleine-Budde [mailto:mkl@pengutronix.de]
>>> Sent: Monday, October 08, 2012 5:32 PM
>>> To: Dong Aisheng-B29396
>>> Cc: Wolfgang Grandegger; Shawn Guo; Linux Netdev List; Linux-CAN; Hui
>>> Wang
>>> Subject: Re: [PATCH] flexcan: disable bus error interrupts for the
>>> i.MX28
>>> Importance: High
>>>
>>> On 10/08/2012 11:13 AM, Dong Aisheng-B29396 wrote:
>>>>>> I just checked our ic guy of flexcan, it seems he also had no sense
>>>>>> of
>>>>> this issue.
>>>>>>
>>>>>> Below is some version info what I got:
>>>>>> Mx6s use FlexCAN3, with IP version 10.00.12.00
>>>>>> Mx53 use FlexCAN2 (with glitch filter), with IP version 03.00.00.00
>>>>>> Mx28 use FlexCAN2 (with glitch filter), with IP version 03.00.04.00
>>>>>> Mx35 use FlexCAN2 (without glitch filter) , with IP version
>>>>>> 03.00.00.00
>>>>>> Mx25 use FlexCAN2 (without glitch filter), with IP version
>>>>>> 03.00.00.00 I'm not sure if mx6q has such issue.
>>>>>
>>>>> OK, we need to find that out experimentally.
>>>>>
>>>> Our IC owner double checked the MX35 and MX53 IP and found the
>>>> RX_WARN & TX_WARN Interrupt source actually are not connected to ARM.
>>>
>>> Does this mean it's a SoC problem, not a problem of the ip core?
>>>
>> It's not a problem of ip core, it's about how to use the IP.
>> I do not know why some i.MX SoCs does not use rx/tx warn interrupts.
>>
>>>> That means flexcan will not trigger interrupt to ARM core even
>>>> RX_WARN or TX_WARN Happens.
>>>> This may be the root cause that why you cannot see RX_WARN interrupt
>>>> if not enable bus error interrupt on mx35.
>>>> He also checked that mx6q has the rx/tx warning interrupt connected
>>>> to
>>> arm.
>>>> So we guess mx6q does not have this issue.
>>>> Anyway, we can test to confirm.
>>>
>>> What about mx25?
>>>
>> For mx25 and mx28, he could not access it now.
>> Will check tomorrow.
>>
> Just let you know:
> The checking result is Mx28 has rx/tx warning interrupt line connected
> while mx25 not.
> Looks align with what we guess.
OK, then I'm going to remove FLEXCAN_HAS_BROKEN_ERR_STATE for the mx6q
as well in the next version of the patch.
Thanks for taking care.
Wolfgang
^ permalink raw reply
* Re: Instead of IP addresses the kernel started to show zero's
From: Dan Carpenter @ 2012-10-09 12:36 UTC (permalink / raw)
To: Alexey Vlasov; +Cc: linux-kernel, netdev
In-Reply-To: <20120921182703.GH16609@beaver>
Add netdev to the CC list.
regards,
dan carpenter
On Fri, Sep 21, 2012 at 10:27:04PM +0400, Alexey Vlasov wrote:
> Hi.
>
> Here it writes LOG module (netfilter) in syslog:
> ====
> Sep 21 22:24:04 l24 kernel: ipsec:SYN-OUTPUT-HTTP IN= OUT=eth0
> SRC=0000000000000000 DST=0000000000000000 LEN=60 TOS=0x00 PREC=0x00
> TTL=64 ID=9042 DF PROTO=TCP SPT=51169 DPT=80 WINDOW=14600 RES=0x00 SYN
> URGP=0 UID=545369 GID=155
> ====
>
> This is recent, here go zero's again.
> ====
> cat /proc/net/xt_recent/j-brute
> src=0000000000000000 ttl: 117 last_seen: 4349942400 oldest_pkt: 1
> 4349942400
> src=0000000000000000 ttl: 119 last_seen: 4349968063 oldest_pkt: 1
> 4349968063
> ====
>
> Can it be fixed without restarting the box?
> Thanks.
>
> # uname -a
> Linux l24 3.4.6 ...
>
> --
> BRGDS. Alexey Vlasov.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: Instead of IP addresses the kernel started to show zero's
From: Eric Dumazet @ 2012-10-09 12:50 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Alexey Vlasov, linux-kernel, netdev, Borislav Petkov
In-Reply-To: <20121009123601.GA21710@mwanda>
On Tue, 2012-10-09 at 15:36 +0300, Dan Carpenter wrote:
> Add netdev to the CC list.
netdev already in the CC list by Borislav Petkov
Reporter was (kindly) requested to try 3.6-rc7 +, and we got no answer.
^ permalink raw reply
* Re: Instead of IP addresses the kernel started to show zero's
From: Dan Carpenter @ 2012-10-09 13:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Alexey Vlasov, linux-kernel, netdev, Borislav Petkov
In-Reply-To: <1349787010.21172.4265.camel@edumazet-glaptop>
On Tue, Oct 09, 2012 at 02:50:10PM +0200, Eric Dumazet wrote:
> On Tue, 2012-10-09 at 15:36 +0300, Dan Carpenter wrote:
> > Add netdev to the CC list.
>
> netdev already in the CC list by Borislav Petkov
>
Sorry. He sent the email twice in two threads and I was still
looking at the first report. :(
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] ipv6: gro: fix PV6_GRO_CB(skb)->proto problem
From: Eric Dumazet @ 2012-10-09 13:06 UTC (permalink / raw)
To: David Miller; +Cc: netdev, herbert
In-Reply-To: <20121008.154148.2288526275691661749.davem@davemloft.net>
On Mon, 2012-10-08 at 15:41 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 08 Oct 2012 21:38:50 +0200
>
> > From: Eric Dumazet <edumazet@google.com>
> >
> > It seems IPV6_GRO_CB(skb)->proto can be destroyed in skb_gro_receive()
> > if a new skb is allocated (to serve as an anchor for frag_list)
> >
> > We copy NAPI_GRO_CB() only (not the IPV6 specific part) in :
> >
> > *NAPI_GRO_CB(nskb) = *NAPI_GRO_CB(p);
> >
> > So we leave IPV6_GRO_CB(nskb)->proto to 0 (fresh skb allocation) instead
> > of IPPROTO_TCP (6)
> >
> > ipv6_gro_complete() isnt able to call ops->gro_complete()
> > [ tcp6_gro_complete() ]
> >
> > Fix this by moving proto in NAPI_GRO_CB() and getting rid of
> > IPV6_GRO_CB
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
>
> Applied and queued up for -stable, thanks Eric.
Hmm, it appears its a false alarm, you can remove it from stable
candidates.
*NAPI_GRO_CB(nskb) = *NAPI_GRO_CB(p);
was in fact redundant with the
memcpy(new->cb, old->cb, sizeof(old->cb));
done in __copy_skb_header()
I'll send a patch to remove this double copy in net-next
Thanks
^ permalink raw reply
* [GIT PULL] Disintegrate UAPI for isdn
From: David Howells @ 2012-10-09 13:30 UTC (permalink / raw)
To: isdn; +Cc: dhowells, isdn4linux, netdev, linux-kernel
Can you merge the following branch into the isdn tree please.
This is to complete part of the Userspace API (UAPI) disintegration for which
the preparatory patches were pulled recently. After these patches, userspace
headers will be segregated into:
include/uapi/linux/.../foo.h
for the userspace interface stuff, and:
include/linux/.../foo.h
for the strictly kernel internal stuff.
---
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-isdn-20121009
for you to fetch changes up to 1855f1b1074ea8a76ced0f3ef25bbecd6b2a7222:
UAPI: (Scripted) Disintegrate include/linux/isdn (2012-10-09 09:48:45 +0100)
----------------------------------------------------------------
UAPI Disintegration 2012-10-09
----------------------------------------------------------------
David Howells (1):
UAPI: (Scripted) Disintegrate include/linux/isdn
include/linux/isdn/Kbuild | 1 -
include/uapi/linux/isdn/Kbuild | 1 +
include/{ => uapi}/linux/isdn/capicmd.h | 0
3 files changed, 1 insertion(+), 1 deletion(-)
rename include/{ => uapi}/linux/isdn/capicmd.h (100%)
.
^ permalink raw reply
* [GIT PULL] Disintegrate UAPI for net
From: David Howells @ 2012-10-09 13:30 UTC (permalink / raw)
To: davem; +Cc: dhowells, netdev, linux-kernel
Can you merge the following branch into the net tree please.
This is to complete part of the Userspace API (UAPI) disintegration for which
the preparatory patches were pulled recently. After these patches, userspace
headers will be segregated into:
include/uapi/linux/.../foo.h
for the userspace interface stuff, and:
include/linux/.../foo.h
for the strictly kernel internal stuff.
---
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-net-20121009
for you to fetch changes up to b6bf56c6be2be7ccebebfd91b1f11889296cbd9e:
UAPI: (Scripted) Disintegrate include/linux/tc_ematch (2012-10-09 09:49:06 +0100)
----------------------------------------------------------------
UAPI Disintegration 2012-10-09
----------------------------------------------------------------
David Howells (9):
UAPI: (Scripted) Disintegrate include/linux/caif
UAPI: (Scripted) Disintegrate include/linux/netfilter
UAPI: (Scripted) Disintegrate include/linux/netfilter/ipset
UAPI: (Scripted) Disintegrate include/linux/netfilter_arp
UAPI: (Scripted) Disintegrate include/linux/netfilter_bridge
UAPI: (Scripted) Disintegrate include/linux/netfilter_ipv4
UAPI: (Scripted) Disintegrate include/linux/netfilter_ipv6
UAPI: (Scripted) Disintegrate include/linux/tc_act
UAPI: (Scripted) Disintegrate include/linux/tc_ematch
include/linux/caif/Kbuild | 2 -
include/linux/netfilter/Kbuild | 77 ------
include/linux/netfilter/ipset/Kbuild | 4 -
include/linux/netfilter/ipset/ip_set.h | 225 +----------------
include/linux/netfilter/ipset/ip_set_bitmap.h | 11 +-
include/linux/netfilter/ipset/ip_set_hash.h | 19 +-
include/linux/netfilter/ipset/ip_set_list.h | 19 +-
include/linux/netfilter/nf_conntrack_common.h | 115 +--------
include/linux/netfilter/nf_conntrack_ftp.h | 16 +-
include/linux/netfilter/nf_conntrack_tcp.h | 49 +---
include/linux/netfilter/nfnetlink.h | 55 +----
include/linux/netfilter/nfnetlink_acct.h | 25 +-
include/linux/netfilter/x_tables.h | 186 +-------------
include/linux/netfilter/xt_hashlimit.h | 71 +-----
include/linux/netfilter/xt_physdev.h | 21 +-
include/linux/netfilter_arp/Kbuild | 2 -
include/linux/netfilter_arp/arp_tables.h | 200 +--------------
include/linux/netfilter_bridge/Kbuild | 18 --
include/linux/netfilter_bridge/ebt_802_3.h | 61 +----
include/linux/netfilter_bridge/ebtables.h | 255 +-------------------
include/linux/netfilter_ipv4/Kbuild | 10 -
include/linux/netfilter_ipv4/ip_tables.h | 218 +----------------
include/linux/netfilter_ipv6/Kbuild | 12 -
include/linux/netfilter_ipv6/ip6_tables.h | 256 +-------------------
include/linux/tc_act/Kbuild | 7 -
include/linux/tc_ematch/Kbuild | 4 -
include/uapi/linux/caif/Kbuild | 2 +
include/{ => uapi}/linux/caif/caif_socket.h | 0
include/{ => uapi}/linux/caif/if_caif.h | 0
include/uapi/linux/netfilter/Kbuild | 76 ++++++
include/uapi/linux/netfilter/ipset/Kbuild | 4 +
include/uapi/linux/netfilter/ipset/ip_set.h | 231 ++++++++++++++++++
include/uapi/linux/netfilter/ipset/ip_set_bitmap.h | 13 +
include/uapi/linux/netfilter/ipset/ip_set_hash.h | 21 ++
include/uapi/linux/netfilter/ipset/ip_set_list.h | 21 ++
include/uapi/linux/netfilter/nf_conntrack_common.h | 117 +++++++++
include/uapi/linux/netfilter/nf_conntrack_ftp.h | 18 ++
.../{ => uapi}/linux/netfilter/nf_conntrack_sctp.h | 0
include/uapi/linux/netfilter/nf_conntrack_tcp.h | 51 ++++
.../linux/netfilter/nf_conntrack_tuple_common.h | 0
include/{ => uapi}/linux/netfilter/nf_nat.h | 0
include/uapi/linux/netfilter/nfnetlink.h | 56 +++++
include/uapi/linux/netfilter/nfnetlink_acct.h | 27 +++
.../{ => uapi}/linux/netfilter/nfnetlink_compat.h | 0
.../linux/netfilter/nfnetlink_conntrack.h | 0
.../linux/netfilter/nfnetlink_cthelper.h | 0
.../linux/netfilter/nfnetlink_cttimeout.h | 0
include/{ => uapi}/linux/netfilter/nfnetlink_log.h | 0
.../{ => uapi}/linux/netfilter/nfnetlink_queue.h | 0
include/uapi/linux/netfilter/x_tables.h | 187 ++++++++++++++
include/{ => uapi}/linux/netfilter/xt_AUDIT.h | 0
include/{ => uapi}/linux/netfilter/xt_CHECKSUM.h | 0
include/{ => uapi}/linux/netfilter/xt_CLASSIFY.h | 0
include/{ => uapi}/linux/netfilter/xt_CONNMARK.h | 0
.../{ => uapi}/linux/netfilter/xt_CONNSECMARK.h | 0
include/{ => uapi}/linux/netfilter/xt_CT.h | 0
include/{ => uapi}/linux/netfilter/xt_DSCP.h | 0
include/{ => uapi}/linux/netfilter/xt_IDLETIMER.h | 0
include/{ => uapi}/linux/netfilter/xt_LED.h | 0
include/{ => uapi}/linux/netfilter/xt_LOG.h | 0
include/{ => uapi}/linux/netfilter/xt_MARK.h | 0
include/{ => uapi}/linux/netfilter/xt_NFLOG.h | 0
include/{ => uapi}/linux/netfilter/xt_NFQUEUE.h | 0
include/{ => uapi}/linux/netfilter/xt_RATEEST.h | 0
include/{ => uapi}/linux/netfilter/xt_SECMARK.h | 0
include/{ => uapi}/linux/netfilter/xt_TCPMSS.h | 0
.../{ => uapi}/linux/netfilter/xt_TCPOPTSTRIP.h | 0
include/{ => uapi}/linux/netfilter/xt_TEE.h | 0
include/{ => uapi}/linux/netfilter/xt_TPROXY.h | 0
include/{ => uapi}/linux/netfilter/xt_addrtype.h | 0
include/{ => uapi}/linux/netfilter/xt_cluster.h | 0
include/{ => uapi}/linux/netfilter/xt_comment.h | 0
include/{ => uapi}/linux/netfilter/xt_connbytes.h | 0
include/{ => uapi}/linux/netfilter/xt_connlimit.h | 0
include/{ => uapi}/linux/netfilter/xt_connmark.h | 0
include/{ => uapi}/linux/netfilter/xt_conntrack.h | 0
include/{ => uapi}/linux/netfilter/xt_cpu.h | 0
include/{ => uapi}/linux/netfilter/xt_dccp.h | 0
include/{ => uapi}/linux/netfilter/xt_devgroup.h | 0
include/{ => uapi}/linux/netfilter/xt_dscp.h | 0
include/{ => uapi}/linux/netfilter/xt_ecn.h | 0
include/{ => uapi}/linux/netfilter/xt_esp.h | 0
include/uapi/linux/netfilter/xt_hashlimit.h | 73 ++++++
include/{ => uapi}/linux/netfilter/xt_helper.h | 0
include/{ => uapi}/linux/netfilter/xt_iprange.h | 0
include/{ => uapi}/linux/netfilter/xt_ipvs.h | 0
include/{ => uapi}/linux/netfilter/xt_length.h | 0
include/{ => uapi}/linux/netfilter/xt_limit.h | 0
include/{ => uapi}/linux/netfilter/xt_mac.h | 0
include/{ => uapi}/linux/netfilter/xt_mark.h | 0
include/{ => uapi}/linux/netfilter/xt_multiport.h | 0
include/{ => uapi}/linux/netfilter/xt_nfacct.h | 0
include/{ => uapi}/linux/netfilter/xt_osf.h | 0
include/{ => uapi}/linux/netfilter/xt_owner.h | 0
include/uapi/linux/netfilter/xt_physdev.h | 23 ++
include/{ => uapi}/linux/netfilter/xt_pkttype.h | 0
include/{ => uapi}/linux/netfilter/xt_policy.h | 0
include/{ => uapi}/linux/netfilter/xt_quota.h | 0
include/{ => uapi}/linux/netfilter/xt_rateest.h | 0
include/{ => uapi}/linux/netfilter/xt_realm.h | 0
include/{ => uapi}/linux/netfilter/xt_recent.h | 0
include/{ => uapi}/linux/netfilter/xt_sctp.h | 0
include/{ => uapi}/linux/netfilter/xt_set.h | 0
include/{ => uapi}/linux/netfilter/xt_socket.h | 0
include/{ => uapi}/linux/netfilter/xt_state.h | 0
include/{ => uapi}/linux/netfilter/xt_statistic.h | 0
include/{ => uapi}/linux/netfilter/xt_string.h | 0
include/{ => uapi}/linux/netfilter/xt_tcpmss.h | 0
include/{ => uapi}/linux/netfilter/xt_tcpudp.h | 0
include/{ => uapi}/linux/netfilter/xt_time.h | 0
include/{ => uapi}/linux/netfilter/xt_u32.h | 0
include/uapi/linux/netfilter_arp/Kbuild | 2 +
include/uapi/linux/netfilter_arp/arp_tables.h | 206 ++++++++++++++++
.../{ => uapi}/linux/netfilter_arp/arpt_mangle.h | 0
include/uapi/linux/netfilter_bridge/Kbuild | 18 ++
include/uapi/linux/netfilter_bridge/ebt_802_3.h | 62 +++++
.../{ => uapi}/linux/netfilter_bridge/ebt_among.h | 0
.../{ => uapi}/linux/netfilter_bridge/ebt_arp.h | 0
.../linux/netfilter_bridge/ebt_arpreply.h | 0
include/{ => uapi}/linux/netfilter_bridge/ebt_ip.h | 0
.../{ => uapi}/linux/netfilter_bridge/ebt_ip6.h | 0
.../{ => uapi}/linux/netfilter_bridge/ebt_limit.h | 0
.../{ => uapi}/linux/netfilter_bridge/ebt_log.h | 0
.../{ => uapi}/linux/netfilter_bridge/ebt_mark_m.h | 0
.../{ => uapi}/linux/netfilter_bridge/ebt_mark_t.h | 0
.../{ => uapi}/linux/netfilter_bridge/ebt_nat.h | 0
.../{ => uapi}/linux/netfilter_bridge/ebt_nflog.h | 0
.../linux/netfilter_bridge/ebt_pkttype.h | 0
.../linux/netfilter_bridge/ebt_redirect.h | 0
.../{ => uapi}/linux/netfilter_bridge/ebt_stp.h | 0
.../{ => uapi}/linux/netfilter_bridge/ebt_ulog.h | 0
.../{ => uapi}/linux/netfilter_bridge/ebt_vlan.h | 0
include/uapi/linux/netfilter_bridge/ebtables.h | 268 +++++++++++++++++++++
include/uapi/linux/netfilter_ipv4/Kbuild | 10 +
include/uapi/linux/netfilter_ipv4/ip_tables.h | 229 ++++++++++++++++++
.../linux/netfilter_ipv4/ipt_CLUSTERIP.h | 0
include/{ => uapi}/linux/netfilter_ipv4/ipt_ECN.h | 0
include/{ => uapi}/linux/netfilter_ipv4/ipt_LOG.h | 0
.../{ => uapi}/linux/netfilter_ipv4/ipt_REJECT.h | 0
include/{ => uapi}/linux/netfilter_ipv4/ipt_TTL.h | 0
include/{ => uapi}/linux/netfilter_ipv4/ipt_ULOG.h | 0
include/{ => uapi}/linux/netfilter_ipv4/ipt_ah.h | 0
include/{ => uapi}/linux/netfilter_ipv4/ipt_ecn.h | 0
include/{ => uapi}/linux/netfilter_ipv4/ipt_ttl.h | 0
include/uapi/linux/netfilter_ipv6/Kbuild | 12 +
include/uapi/linux/netfilter_ipv6/ip6_tables.h | 267 ++++++++++++++++++++
include/{ => uapi}/linux/netfilter_ipv6/ip6t_HL.h | 0
include/{ => uapi}/linux/netfilter_ipv6/ip6t_LOG.h | 0
include/{ => uapi}/linux/netfilter_ipv6/ip6t_NPT.h | 0
.../{ => uapi}/linux/netfilter_ipv6/ip6t_REJECT.h | 0
include/{ => uapi}/linux/netfilter_ipv6/ip6t_ah.h | 0
.../{ => uapi}/linux/netfilter_ipv6/ip6t_frag.h | 0
include/{ => uapi}/linux/netfilter_ipv6/ip6t_hl.h | 0
.../linux/netfilter_ipv6/ip6t_ipv6header.h | 0
include/{ => uapi}/linux/netfilter_ipv6/ip6t_mh.h | 0
.../{ => uapi}/linux/netfilter_ipv6/ip6t_opts.h | 0
include/{ => uapi}/linux/netfilter_ipv6/ip6t_rt.h | 0
include/uapi/linux/tc_act/Kbuild | 7 +
include/{ => uapi}/linux/tc_act/tc_csum.h | 0
include/{ => uapi}/linux/tc_act/tc_gact.h | 0
include/{ => uapi}/linux/tc_act/tc_ipt.h | 0
include/{ => uapi}/linux/tc_act/tc_mirred.h | 0
include/{ => uapi}/linux/tc_act/tc_nat.h | 0
include/{ => uapi}/linux/tc_act/tc_pedit.h | 0
include/{ => uapi}/linux/tc_act/tc_skbedit.h | 0
include/uapi/linux/tc_ematch/Kbuild | 4 +
include/{ => uapi}/linux/tc_ematch/tc_em_cmp.h | 0
include/{ => uapi}/linux/tc_ematch/tc_em_meta.h | 0
include/{ => uapi}/linux/tc_ematch/tc_em_nbyte.h | 0
include/{ => uapi}/linux/tc_ematch/tc_em_text.h | 0
170 files changed, 2026 insertions(+), 1917 deletions(-)
rename include/{ => uapi}/linux/caif/caif_socket.h (100%)
rename include/{ => uapi}/linux/caif/if_caif.h (100%)
create mode 100644 include/uapi/linux/netfilter/ipset/ip_set.h
create mode 100644 include/uapi/linux/netfilter/ipset/ip_set_bitmap.h
create mode 100644 include/uapi/linux/netfilter/ipset/ip_set_hash.h
create mode 100644 include/uapi/linux/netfilter/ipset/ip_set_list.h
create mode 100644 include/uapi/linux/netfilter/nf_conntrack_common.h
create mode 100644 include/uapi/linux/netfilter/nf_conntrack_ftp.h
rename include/{ => uapi}/linux/netfilter/nf_conntrack_sctp.h (100%)
create mode 100644 include/uapi/linux/netfilter/nf_conntrack_tcp.h
rename include/{ => uapi}/linux/netfilter/nf_conntrack_tuple_common.h (100%)
rename include/{ => uapi}/linux/netfilter/nf_nat.h (100%)
create mode 100644 include/uapi/linux/netfilter/nfnetlink.h
create mode 100644 include/uapi/linux/netfilter/nfnetlink_acct.h
rename include/{ => uapi}/linux/netfilter/nfnetlink_compat.h (100%)
rename include/{ => uapi}/linux/netfilter/nfnetlink_conntrack.h (100%)
rename include/{ => uapi}/linux/netfilter/nfnetlink_cthelper.h (100%)
rename include/{ => uapi}/linux/netfilter/nfnetlink_cttimeout.h (100%)
rename include/{ => uapi}/linux/netfilter/nfnetlink_log.h (100%)
rename include/{ => uapi}/linux/netfilter/nfnetlink_queue.h (100%)
create mode 100644 include/uapi/linux/netfilter/x_tables.h
rename include/{ => uapi}/linux/netfilter/xt_AUDIT.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_CHECKSUM.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_CLASSIFY.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_CONNMARK.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_CONNSECMARK.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_CT.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_DSCP.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_IDLETIMER.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_LED.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_LOG.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_MARK.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_NFLOG.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_NFQUEUE.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_RATEEST.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_SECMARK.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_TCPMSS.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_TCPOPTSTRIP.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_TEE.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_TPROXY.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_addrtype.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_cluster.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_comment.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_connbytes.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_connlimit.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_connmark.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_conntrack.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_cpu.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_dccp.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_devgroup.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_dscp.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_ecn.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_esp.h (100%)
create mode 100644 include/uapi/linux/netfilter/xt_hashlimit.h
rename include/{ => uapi}/linux/netfilter/xt_helper.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_iprange.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_ipvs.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_length.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_limit.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_mac.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_mark.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_multiport.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_nfacct.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_osf.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_owner.h (100%)
create mode 100644 include/uapi/linux/netfilter/xt_physdev.h
rename include/{ => uapi}/linux/netfilter/xt_pkttype.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_policy.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_quota.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_rateest.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_realm.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_recent.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_sctp.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_set.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_socket.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_state.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_statistic.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_string.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_tcpmss.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_tcpudp.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_time.h (100%)
rename include/{ => uapi}/linux/netfilter/xt_u32.h (100%)
create mode 100644 include/uapi/linux/netfilter_arp/arp_tables.h
rename include/{ => uapi}/linux/netfilter_arp/arpt_mangle.h (100%)
create mode 100644 include/uapi/linux/netfilter_bridge/ebt_802_3.h
rename include/{ => uapi}/linux/netfilter_bridge/ebt_among.h (100%)
rename include/{ => uapi}/linux/netfilter_bridge/ebt_arp.h (100%)
rename include/{ => uapi}/linux/netfilter_bridge/ebt_arpreply.h (100%)
rename include/{ => uapi}/linux/netfilter_bridge/ebt_ip.h (100%)
rename include/{ => uapi}/linux/netfilter_bridge/ebt_ip6.h (100%)
rename include/{ => uapi}/linux/netfilter_bridge/ebt_limit.h (100%)
rename include/{ => uapi}/linux/netfilter_bridge/ebt_log.h (100%)
rename include/{ => uapi}/linux/netfilter_bridge/ebt_mark_m.h (100%)
rename include/{ => uapi}/linux/netfilter_bridge/ebt_mark_t.h (100%)
rename include/{ => uapi}/linux/netfilter_bridge/ebt_nat.h (100%)
rename include/{ => uapi}/linux/netfilter_bridge/ebt_nflog.h (100%)
rename include/{ => uapi}/linux/netfilter_bridge/ebt_pkttype.h (100%)
rename include/{ => uapi}/linux/netfilter_bridge/ebt_redirect.h (100%)
rename include/{ => uapi}/linux/netfilter_bridge/ebt_stp.h (100%)
rename include/{ => uapi}/linux/netfilter_bridge/ebt_ulog.h (100%)
rename include/{ => uapi}/linux/netfilter_bridge/ebt_vlan.h (100%)
create mode 100644 include/uapi/linux/netfilter_bridge/ebtables.h
create mode 100644 include/uapi/linux/netfilter_ipv4/ip_tables.h
rename include/{ => uapi}/linux/netfilter_ipv4/ipt_CLUSTERIP.h (100%)
rename include/{ => uapi}/linux/netfilter_ipv4/ipt_ECN.h (100%)
rename include/{ => uapi}/linux/netfilter_ipv4/ipt_LOG.h (100%)
rename include/{ => uapi}/linux/netfilter_ipv4/ipt_REJECT.h (100%)
rename include/{ => uapi}/linux/netfilter_ipv4/ipt_TTL.h (100%)
rename include/{ => uapi}/linux/netfilter_ipv4/ipt_ULOG.h (100%)
rename include/{ => uapi}/linux/netfilter_ipv4/ipt_ah.h (100%)
rename include/{ => uapi}/linux/netfilter_ipv4/ipt_ecn.h (100%)
rename include/{ => uapi}/linux/netfilter_ipv4/ipt_ttl.h (100%)
create mode 100644 include/uapi/linux/netfilter_ipv6/ip6_tables.h
rename include/{ => uapi}/linux/netfilter_ipv6/ip6t_HL.h (100%)
rename include/{ => uapi}/linux/netfilter_ipv6/ip6t_LOG.h (100%)
rename include/{ => uapi}/linux/netfilter_ipv6/ip6t_NPT.h (100%)
rename include/{ => uapi}/linux/netfilter_ipv6/ip6t_REJECT.h (100%)
rename include/{ => uapi}/linux/netfilter_ipv6/ip6t_ah.h (100%)
rename include/{ => uapi}/linux/netfilter_ipv6/ip6t_frag.h (100%)
rename include/{ => uapi}/linux/netfilter_ipv6/ip6t_hl.h (100%)
rename include/{ => uapi}/linux/netfilter_ipv6/ip6t_ipv6header.h (100%)
rename include/{ => uapi}/linux/netfilter_ipv6/ip6t_mh.h (100%)
rename include/{ => uapi}/linux/netfilter_ipv6/ip6t_opts.h (100%)
rename include/{ => uapi}/linux/netfilter_ipv6/ip6t_rt.h (100%)
rename include/{ => uapi}/linux/tc_act/tc_csum.h (100%)
rename include/{ => uapi}/linux/tc_act/tc_gact.h (100%)
rename include/{ => uapi}/linux/tc_act/tc_ipt.h (100%)
rename include/{ => uapi}/linux/tc_act/tc_mirred.h (100%)
rename include/{ => uapi}/linux/tc_act/tc_nat.h (100%)
rename include/{ => uapi}/linux/tc_act/tc_pedit.h (100%)
rename include/{ => uapi}/linux/tc_act/tc_skbedit.h (100%)
rename include/{ => uapi}/linux/tc_ematch/tc_em_cmp.h (100%)
rename include/{ => uapi}/linux/tc_ematch/tc_em_meta.h (100%)
rename include/{ => uapi}/linux/tc_ematch/tc_em_nbyte.h (100%)
rename include/{ => uapi}/linux/tc_ematch/tc_em_text.h (100%)
.
^ permalink raw reply
* compound skb frag pages appearing in start_xmit
From: Ian Campbell @ 2012-10-09 13:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: xen-devel, netdev, Konrad Rzeszutek Wilk, Sander Eikelenboom
Hi Eric,
Sander has discovered an issue where xen-netback is given a compound
page as one of the skb frag pages to transmit. Currently netback can
only handle PAGE_SIZE'd frags and bugs out.
I suspect this is something to do with 69b08f62e174 "net: use bigger
pages in __netdev_alloc_frag", although perhaps not because it looks
like only tg3 uses it and Sander has an r8169. Also tg3 seems to only
call netdev_alloc_frag for sizes < PAGE_SIZE. I'm probably missing
something.
Are all net drivers expected to be able to handle compound pages in the
frags? Obviously it is to their benefit to do so, so it is something
I'll want to look into for netback.
I expect the main factor here is bridging/forwarding, since the
receiving NIC and its driver appear to support compound pages but the
outgoing NIC (netback in this case) does not.
I guess my question is should I be rushing to fix netback ASAP or should
I rather be looking for a bug somewhere which caused a frag of this type
to get as far as netback's start_xmit in the first place?
Or am I just barking up the wrong tree to start with?
Thanks,
Ian.
^ permalink raw reply
* Re: compound skb frag pages appearing in start_xmit
From: Eric Dumazet @ 2012-10-09 13:54 UTC (permalink / raw)
To: Ian Campbell
Cc: Eric Dumazet, xen-devel, netdev, Konrad Rzeszutek Wilk,
Sander Eikelenboom
In-Reply-To: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
On Tue, 2012-10-09 at 14:47 +0100, Ian Campbell wrote:
> Hi Eric,
>
Hi Ian
> Sander has discovered an issue where xen-netback is given a compound
> page as one of the skb frag pages to transmit. Currently netback can
> only handle PAGE_SIZE'd frags and bugs out.
>
> I suspect this is something to do with 69b08f62e174 "net: use bigger
> pages in __netdev_alloc_frag", although perhaps not because it looks
> like only tg3 uses it and Sander has an r8169. Also tg3 seems to only
> call netdev_alloc_frag for sizes < PAGE_SIZE. I'm probably missing
> something.
Its not the commit you want ;)
>
> Are all net drivers expected to be able to handle compound pages in the
> frags? Obviously it is to their benefit to do so, so it is something
> I'll want to look into for netback.
>
Not sure why a net driver would care of COMPOUND page at all ?
a Fragment has a struct page *, and a size.
a page can be order-0, order-1, order-2, order-3, ...
> I expect the main factor here is bridging/forwarding, since the
> receiving NIC and its driver appear to support compound pages but the
> outgoing NIC (netback in this case) does not.
>
> I guess my question is should I be rushing to fix netback ASAP or should
> I rather be looking for a bug somewhere which caused a frag of this type
> to get as far as netback's start_xmit in the first place?
>
> Or am I just barking up the wrong tree to start with?
The problem comes because of
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=5640f7685831e088fe6c2e1f863a6805962f8e81
And yes, we must find a way to cope with this problem in your driver,
because you can also benefit from increase of performance once fixed ;)
And yes I can certainly help, as I am the author of this patch ;)
Thanks
^ permalink raw reply
* Re: [PATCHv4 1/4] modem_shm: Add Modem Access Framework
From: Greg KH @ 2012-10-09 13:59 UTC (permalink / raw)
To: Arun MURTHY
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-doc@vger.kernel.org, alan@lxorguk.ukuu.org.uk
In-Reply-To: <F45880696056844FA6A73F415B568C695B697CB0C9@EXDCVYMBSTM006.EQ1STM.local>
On Tue, Oct 09, 2012 at 07:37:02AM +0200, Arun MURTHY wrote:
> Any further comments?
I was waiting for you to address all of the previous ones with a new set
of patches before burdening you with anything new :)
greg k-h
^ permalink raw reply
* Re: compound skb frag pages appearing in start_xmit
From: Eric Dumazet @ 2012-10-09 14:01 UTC (permalink / raw)
To: Ian Campbell
Cc: Eric Dumazet, xen-devel, netdev, Konrad Rzeszutek Wilk,
Sander Eikelenboom
In-Reply-To: <1349790863.21172.4406.camel@edumazet-glaptop>
On Tue, 2012-10-09 at 15:54 +0200, Eric Dumazet wrote:
> On Tue, 2012-10-09 at 14:47 +0100, Ian Campbell wrote:
> > Hi Eric,
> >
>
> Hi Ian
>
> > Sander has discovered an issue where xen-netback is given a compound
> > page as one of the skb frag pages to transmit. Currently netback can
> > only handle PAGE_SIZE'd frags and bugs out.
> >
> > I suspect this is something to do with 69b08f62e174 "net: use bigger
> > pages in __netdev_alloc_frag", although perhaps not because it looks
> > like only tg3 uses it and Sander has an r8169. Also tg3 seems to only
> > call netdev_alloc_frag for sizes < PAGE_SIZE. I'm probably missing
> > something.
>
>
> Its not the commit you want ;)
Hmm, I take it back. It also can give you the same problem :
We use this allocator for rx path of drivers :
__netdev_alloc_skb()
So its now absolutely possible that one skb->head is backed by a order-3
page.
Is the problem coming from xen_netbk_count_skb_slots() ?
Give me more information if you want me to help.
^ permalink raw reply
* Re: compound skb frag pages appearing in start_xmit
From: Ian Campbell @ 2012-10-09 14:17 UTC (permalink / raw)
To: Eric Dumazet
Cc: Eric Dumazet, xen-devel, netdev@vger.kernel.org,
Konrad Rzeszutek Wilk, Sander Eikelenboom
In-Reply-To: <1349790863.21172.4406.camel@edumazet-glaptop>
On Tue, 2012-10-09 at 14:54 +0100, Eric Dumazet wrote:
> On Tue, 2012-10-09 at 14:47 +0100, Ian Campbell wrote:
> > Hi Eric,
> >
>
> Hi Ian
>
> > Sander has discovered an issue where xen-netback is given a compound
> > page as one of the skb frag pages to transmit. Currently netback can
> > only handle PAGE_SIZE'd frags and bugs out.
> >
> > I suspect this is something to do with 69b08f62e174 "net: use bigger
> > pages in __netdev_alloc_frag", although perhaps not because it looks
> > like only tg3 uses it and Sander has an r8169. Also tg3 seems to only
> > call netdev_alloc_frag for sizes < PAGE_SIZE. I'm probably missing
> > something.
>
>
> Its not the commit you want ;)
>
> >
> > Are all net drivers expected to be able to handle compound pages in the
> > frags? Obviously it is to their benefit to do so, so it is something
> > I'll want to look into for netback.
> >
>
> Not sure why a net driver would care of COMPOUND page at all ?
>
> a Fragment has a struct page *, and a size.
>
> a page can be order-0, order-1, order-2, order-3, ...
I keep falling into this trap that a struct page * can be order > 0.
The Xen PV interfaces deal in order-0 pages only. Also things which are
contiguous in physical space may not be contiguous in DMA space (which
we call "machine memory" in Xen terminology).
The first is probably a specific quirk of Xen, but I thought there were
other architectures where physical and DMA space we not necessarily
contiguous and which would therefore need special handling (I guess
those platforms all have IOMMUs)
> > I expect the main factor here is bridging/forwarding, since the
> > receiving NIC and its driver appear to support compound pages but the
> > outgoing NIC (netback in this case) does not.
> >
> > I guess my question is should I be rushing to fix netback ASAP or should
> > I rather be looking for a bug somewhere which caused a frag of this type
> > to get as far as netback's start_xmit in the first place?
> >
> > Or am I just barking up the wrong tree to start with?
>
>
>
> The problem comes because of
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=5640f7685831e088fe6c2e1f863a6805962f8e81
>
> And yes, we must find a way to cope with this problem in your driver,
> because you can also benefit from increase of performance once fixed ;)
>
> And yes I can certainly help, as I am the author of this patch ;)
I think I can mostly deal with this in the same way netback deals with
large skb heads i.e. by busting the multipage page into individual 4096
page chunks.
Does the higher order pages effectively reduce the number of frags which
are in use? e.g if MAX_SKB_FRAGS is 16, then for order-0 pages you could
have 64K worth of frag data.
If we switch to order-3 pages everywhere then can the skb contain 512K
of data, or does the effective maximum number of frags in an skb reduce
to 2?
If it's the latter then I think fixing netback is simple, if it's the
former then I might need to think a bit harder.
Ian.
^ permalink raw reply
* Re: compound skb frag pages appearing in start_xmit
From: Ian Campbell @ 2012-10-09 14:23 UTC (permalink / raw)
To: Eric Dumazet
Cc: Eric Dumazet, xen-devel, netdev@vger.kernel.org,
Konrad Rzeszutek Wilk, Sander Eikelenboom
In-Reply-To: <1349791305.21172.4425.camel@edumazet-glaptop>
On Tue, 2012-10-09 at 15:01 +0100, Eric Dumazet wrote:
> On Tue, 2012-10-09 at 15:54 +0200, Eric Dumazet wrote:
> > On Tue, 2012-10-09 at 14:47 +0100, Ian Campbell wrote:
> > > Hi Eric,
> > >
> >
> > Hi Ian
> >
> > > Sander has discovered an issue where xen-netback is given a compound
> > > page as one of the skb frag pages to transmit. Currently netback can
> > > only handle PAGE_SIZE'd frags and bugs out.
> > >
> > > I suspect this is something to do with 69b08f62e174 "net: use bigger
> > > pages in __netdev_alloc_frag", although perhaps not because it looks
> > > like only tg3 uses it and Sander has an r8169. Also tg3 seems to only
> > > call netdev_alloc_frag for sizes < PAGE_SIZE. I'm probably missing
> > > something.
> >
> >
> > Its not the commit you want ;)
>
> Hmm, I take it back. It also can give you the same problem :
>
> We use this allocator for rx path of drivers :
>
> __netdev_alloc_skb()
>
> So its now absolutely possible that one skb->head is backed by a order-3
> page.
>
> Is the problem coming from xen_netbk_count_skb_slots() ?
>
> Give me more information if you want me to help.
The interesting code is in netbk_gop_skb(), specifically the two calls
to netbk_gop_frag_copy.
netbk_gop_frag_copy can only copy order-0 pages to the peer since they
go over a shared ring transport which can only deal in order-0 pages.
For the SKB head there is a loop which handles order>0 heads, I suspect
we just need something similar for the frag case.
Although see my question in the other response about the maximum number
of frags we can have when order is > 0 since if using larger pages
causes us to end up with a much larger number of order-0 pages once
we've broken them up then we have a problem and I need to put my
thinking cap on a bit (perhaps substantially) tighter.
Konrad, it looks like netfront has a similar issue in
xennet_make_frags() since it doesn't shatter large order mappings
either.
Ian.
^ permalink raw reply
* Re: compound skb frag pages appearing in start_xmit
From: Eric Dumazet @ 2012-10-09 14:27 UTC (permalink / raw)
To: Ian Campbell
Cc: Eric Dumazet, xen-devel, netdev@vger.kernel.org,
Konrad Rzeszutek Wilk, Sander Eikelenboom
In-Reply-To: <1349792241.21847.199.camel@zakaz.uk.xensource.com>
On Tue, 2012-10-09 at 15:17 +0100, Ian Campbell wrote:
> Does the higher order pages effectively reduce the number of frags which
> are in use? e.g if MAX_SKB_FRAGS is 16, then for order-0 pages you could
> have 64K worth of frag data.
>
> If we switch to order-3 pages everywhere then can the skb contain 512K
> of data, or does the effective maximum number of frags in an skb reduce
> to 2?
effective number of frags reduce to 2 or 3
(We still limit GSO packets to ~63536 bytes)
^ permalink raw reply
* Re: compound skb frag pages appearing in start_xmit
From: Eric Dumazet @ 2012-10-09 14:33 UTC (permalink / raw)
To: Ian Campbell
Cc: Eric Dumazet, xen-devel, netdev@vger.kernel.org,
Konrad Rzeszutek Wilk, Sander Eikelenboom
In-Reply-To: <1349792617.21847.205.camel@zakaz.uk.xensource.com>
On Tue, 2012-10-09 at 15:23 +0100, Ian Campbell wrote:
> On Tue, 2012-10-09 at 15:01 +0100, Eric Dumazet wrote:
> > On Tue, 2012-10-09 at 15:54 +0200, Eric Dumazet wrote:
> > > On Tue, 2012-10-09 at 14:47 +0100, Ian Campbell wrote:
> > > > Hi Eric,
> > > >
> > >
> > > Hi Ian
> > >
> > > > Sander has discovered an issue where xen-netback is given a compound
> > > > page as one of the skb frag pages to transmit. Currently netback can
> > > > only handle PAGE_SIZE'd frags and bugs out.
> > > >
> > > > I suspect this is something to do with 69b08f62e174 "net: use bigger
> > > > pages in __netdev_alloc_frag", although perhaps not because it looks
> > > > like only tg3 uses it and Sander has an r8169. Also tg3 seems to only
> > > > call netdev_alloc_frag for sizes < PAGE_SIZE. I'm probably missing
> > > > something.
> > >
> > >
> > > Its not the commit you want ;)
> >
> > Hmm, I take it back. It also can give you the same problem :
> >
> > We use this allocator for rx path of drivers :
> >
> > __netdev_alloc_skb()
> >
> > So its now absolutely possible that one skb->head is backed by a order-3
> > page.
> >
> > Is the problem coming from xen_netbk_count_skb_slots() ?
> >
> > Give me more information if you want me to help.
>
> The interesting code is in netbk_gop_skb(), specifically the two calls
> to netbk_gop_frag_copy.
>
> netbk_gop_frag_copy can only copy order-0 pages to the peer since they
> go over a shared ring transport which can only deal in order-0 pages.
>
> For the SKB head there is a loop which handles order>0 heads, I suspect
> we just need something similar for the frag case.
>
> Although see my question in the other response about the maximum number
> of frags we can have when order is > 0 since if using larger pages
> causes us to end up with a much larger number of order-0 pages once
> we've broken them up then we have a problem and I need to put my
> thinking cap on a bit (perhaps substantially) tighter.
>
> Konrad, it looks like netfront has a similar issue in
> xennet_make_frags() since it doesn't shatter large order mappings
> either.
Hmm...
In theory, if a skb has 16+1 frags backed by compound pages, you could
need ~48 order-0 frags.
(4098 bytes could need 1-4096-1 (3 frags))
In practice, it should be around ~17 order-0 frags as before.
^ permalink raw reply
* Re: compound skb frag pages appearing in start_xmit
From: Ian Campbell @ 2012-10-09 14:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: Eric Dumazet, xen-devel, netdev@vger.kernel.org,
Konrad Rzeszutek Wilk, Sander Eikelenboom
In-Reply-To: <1349792847.21172.4479.camel@edumazet-glaptop>
On Tue, 2012-10-09 at 15:27 +0100, Eric Dumazet wrote:
> On Tue, 2012-10-09 at 15:17 +0100, Ian Campbell wrote:
>
> > Does the higher order pages effectively reduce the number of frags which
> > are in use? e.g if MAX_SKB_FRAGS is 16, then for order-0 pages you could
> > have 64K worth of frag data.
> >
> > If we switch to order-3 pages everywhere then can the skb contain 512K
> > of data, or does the effective maximum number of frags in an skb reduce
> > to 2?
>
> effective number of frags reduce to 2 or 3
>
> (We still limit GSO packets to ~63536 bytes)
Great! Then I think the fix is more/less trivial...
As an aside, when the skb head is < 4096 bytes is that necessarily a
compound page or might it just be a large kmalloc area?
Only really relevant since it impacts the possibility for code sharing
between the head and the frags sending.
Ian
^ permalink raw reply
* Re: compound skb frag pages appearing in start_xmit
From: Ian Campbell @ 2012-10-09 14:54 UTC (permalink / raw)
To: Eric Dumazet
Cc: Eric Dumazet, xen-devel, netdev@vger.kernel.org,
Konrad Rzeszutek Wilk, Sander Eikelenboom
In-Reply-To: <1349793217.21172.4497.camel@edumazet-glaptop>
On Tue, 2012-10-09 at 15:33 +0100, Eric Dumazet wrote:
> On Tue, 2012-10-09 at 15:23 +0100, Ian Campbell wrote:
> > On Tue, 2012-10-09 at 15:01 +0100, Eric Dumazet wrote:
> > > On Tue, 2012-10-09 at 15:54 +0200, Eric Dumazet wrote:
> > > > On Tue, 2012-10-09 at 14:47 +0100, Ian Campbell wrote:
> > > > > Hi Eric,
> > > > >
> > > >
> > > > Hi Ian
> > > >
> > > > > Sander has discovered an issue where xen-netback is given a compound
> > > > > page as one of the skb frag pages to transmit. Currently netback can
> > > > > only handle PAGE_SIZE'd frags and bugs out.
> > > > >
> > > > > I suspect this is something to do with 69b08f62e174 "net: use bigger
> > > > > pages in __netdev_alloc_frag", although perhaps not because it looks
> > > > > like only tg3 uses it and Sander has an r8169. Also tg3 seems to only
> > > > > call netdev_alloc_frag for sizes < PAGE_SIZE. I'm probably missing
> > > > > something.
> > > >
> > > >
> > > > Its not the commit you want ;)
> > >
> > > Hmm, I take it back. It also can give you the same problem :
> > >
> > > We use this allocator for rx path of drivers :
> > >
> > > __netdev_alloc_skb()
> > >
> > > So its now absolutely possible that one skb->head is backed by a order-3
> > > page.
> > >
> > > Is the problem coming from xen_netbk_count_skb_slots() ?
> > >
> > > Give me more information if you want me to help.
> >
> > The interesting code is in netbk_gop_skb(), specifically the two calls
> > to netbk_gop_frag_copy.
> >
> > netbk_gop_frag_copy can only copy order-0 pages to the peer since they
> > go over a shared ring transport which can only deal in order-0 pages.
> >
> > For the SKB head there is a loop which handles order>0 heads, I suspect
> > we just need something similar for the frag case.
> >
> > Although see my question in the other response about the maximum number
> > of frags we can have when order is > 0 since if using larger pages
> > causes us to end up with a much larger number of order-0 pages once
> > we've broken them up then we have a problem and I need to put my
> > thinking cap on a bit (perhaps substantially) tighter.
> >
> > Konrad, it looks like netfront has a similar issue in
> > xennet_make_frags() since it doesn't shatter large order mappings
> > either.
>
> Hmm...
>
> In theory, if a skb has 16+1 frags backed by compound pages, you could
> need ~48 order-0 frags.
>
> (4098 bytes could need 1-4096-1 (3 frags))
>
> In practice, it should be around ~17 order-0 frags as before.
Right, thanks. I think I can cope with that without needing to change
the PV protocol in any way.
Ian.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox