gmane.linux.network

Re: [PATCH net-next 20/22] sfc: reuse pages to avoid DMA mapping/unmapping costs

Ben Hutchings — 2013-05-22T17:43:02

[...]

Since we don't try to use the iommu_group itself, those functions don't
seem to be appropriate.


That's the test we use OOT for older kernel version.  However I advised
Daniel, apparently wrongly, that testing iommu_group would now be more
accurate.


Unfortunately the pSeries IOMMU code doesn't support iommu_ops yet, and
that is precisely the case where DMA map/unmap operations are most
expensive (that we've seen).


Right.  The real question the driver should ask is: 'will DMA-mapping/
unmapping for this device be significantly slower than DMA-syncing?'  We
don't yet have a way to ask that; maybe that should be added to the DMA
API.

Ben.

Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes

Sebastian Hesselbarth — 2013-05-22T17:42:36

Hmm, maybe a little bit too early. While restoring the MAC address now
works, another bug arises which I guess is related with phy setup
and aneg.

Will investigate and update patch set accordingly.

Sebastian

Re: possible bug in IPv6 MLD retransmissions

Flavio Leitner — 2013-05-22T17:27:11

It becomes a bug (and that's why I started with 'possible') if dad
completes after the two MLD reports sent with ``::'' source, because
routers will ignore those initial reports and the system is left out.

Thanks,

tg3 transmit timeout on 5720 / Dell R720

Roland Dreier — 2013-05-22T17:02:31

From: Roland Dreier <roland< at >purestorage.com>

Hi tg3 maintainers,

We have some Dell R720 systems with quad Broadcom gigabit ethernet adapters:

[    1.461023] tg3 0000:02:00.0: eth0: Tigon3 [partno(BCM95720) rev 5720000] (PCI Express) MAC address 90:b1:1c:3f:46:b8
[    1.461026] tg3 0000:02:00.0: eth0: attached PHY is 5720C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])

Running kernel 3.6.11 (and also some experiments with newer kernels),
on _some_ systems/ports, we see a transmit timeout (see below for full
log).  It appears that the very first packet that the driver tries to
send never completes and we immediately hit the netdev watchdog.

The strange thing is that this doesn't happen with all systems, and
in fact even on the affected system it only affects one of the four
ethernet devices (which seem to be two dual-port PCIe devices).

Running ethtool -t offline on a broken device gives:

    The test result is FAIL
    The test extra info:
    nvram test        (online)       0
    link test

Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes

Jason Gunthorpe — 2013-05-22T16:59:08


Sorry, no, we don't use ATAGs here, our platforms start the kernel
with a correct DTB that has the correct mac address to use. My patch
was to have the driver accept it, and I think Sebastian has already
got that functionality...

Jason

Re: [PATCH net-next 20/22] sfc: reuse pages to avoid DMA mapping/unmapping costs

Alex Williamson — 2013-05-22T16:29:09


I'm not sure I agree with the test for whether an IOMMU is present...

b/drivers/net/ethernet/sfc/efx.c
[snip]

Testing for an iommu_group is more of a test of (is an iommu present && does 
it support the iommu api && does it support iommu groups && is the device 
isolatable).  That doesn't seem like what we want here (besides, it's kind 
of a hacky sidestep to the API which would suggest using iommu_group_get/put 
here).

We could use iommu_present(&pci_bus_type), which reduces the test to (iommu 
present && supports iommu api (ie. iommu_ops)).  Better, but I think you 
really care about an iommu present with dma_ops.  I think we can assume that 
if an iommu supports iommu_ops, it supports dma_ops, but that still leaves 
out iommus that do not support iommu_ops.  Do we care about those?

Furthermore, what about cases where an iommu is present, but unused?  For 
example, iommu=pt (passthrough).  I'd think the driver would want to behave 
as it would in the non-iommu case in that configuration.  Anyway, I d

[PATCH net-next V3 2/3] xen-netfront: split event channels support for Xen frontend driver

Wei Liu — 2013-05-22T16:34:46

This patch adds a new feature called feature-split-event-channels for
netfront, enabling it to handle TX and RX events separately.

If netback does not support this feature, it falls back to use single event
channel.

If netfront fails to setup split event channels, it will try falling back to
single event channel.

Signed-off-by: Wei Liu <wei.liu2< at >citrix.com>
Reviewed-by: David Vrabel <david.vrabel< at >citrix.com>
---
 drivers/net/xen-netfront.c |  178 ++++++++++++++++++++++++++++++++++++--------
 1 file changed, 149 insertions(+), 29 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 5770e3b..62238a0 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
< at >< at > -85,7 +85,15 < at >< at > struct netfront_info {
 
 struct napi_struct napi;
 
-unsigned int evtchn;
+/* Split event channels support, tx_* == rx_* when using
+ * single event channel.
+ */
+unsigned int tx_evtchn, rx_evtchn;
+unsigned int tx_irq, rx_irq;
+/* Only used when split event channels support i

[PATCH net-next V3 3/3] xen: netif.h: document feature-split-event-channels

Wei Liu — 2013-05-22T16:34:47

This patch synchronises documentation for feature-split-event-channels from
Xen canonical header file.

Signed-off-by: Wei Liu <wei.liu2< at >citrix.com>
---
 include/xen/interface/io/netif.h |   12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/include/xen/interface/io/netif.h b/include/xen/interface/io/netif.h
index 3ef3fe0..eb262e3 100644
--- a/include/xen/interface/io/netif.h
+++ b/include/xen/interface/io/netif.h
< at >< at > -38,6 +38,18 < at >< at >
  * that it cannot safely queue packets (as it may not be kicked to send them).
  */
 
+ /*
+ * "feature-split-event-channels" is introduced to separate guest TX
+ * and RX notificaion. Backend either doesn't support this feature or
+ * advertise it via xenstore as 0 (disabled) or 1 (enabled).
+ *
+ * To make use of this feature, frontend should allocate two event
+ * channels for TX and RX, advertise them to backend as
+ * "event-channel-tx" and "event-channel-rx" respectively. If frontend
+ * doesn't want to use this feature, it just writes "event-channel"
+ * node

[PATCH net-next V3 1/3] xen-netback: split event channels support for Xen backend driver

Wei Liu — 2013-05-22T16:34:45

Netback and netfront only use one event channel to do TX / RX notification,
which may cause unnecessary wake-up of processing routines. This patch adds a
new feature called feature-split-event-channels to netback, enabling it to
handle TX and RX events separately.

Netback will use tx_irq to notify guest for TX completion, rx_irq for RX
notification.

If frontend doesn't support this feature, tx_irq equals to rx_irq.

Signed-off-by: Wei Liu <wei.liu2< at >citrix.com>
---
 drivers/net/xen-netback/common.h    |   13 ++++--
 drivers/net/xen-netback/interface.c |   85 ++++++++++++++++++++++++++++-------
 drivers/net/xen-netback/netback.c   |   14 ++++--
 drivers/net/xen-netback/xenbus.c    |   41 ++++++++++++++---
 4 files changed, 124 insertions(+), 29 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 6102a6c..8a4d77e 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
< at >< at > -57,8 +57,12 < at >< at > struct xenvif {
 
 u8               fe_dev_ad

[PATCH net-next 0/2 V3] Xen network: split event channels support

Wei Liu — 2013-05-22T16:34:44

This series adds a new feature called split event channels.

In the original implementation, only one event channel is setup between
frontend and backend. This is not ideal as TX notification interferes with RX
notification. Using dedicated event channels for TX and RX solves this issue.

Changes since V2:
* feature_split_event_channels -> separate_tx_rx_irq
* make separate_tx_rx_irq bool
* document this feature in header file
* don't report fatal if writing feature to xenstore fails
* frontend will fall back to single event channel if new feature setup fails

Changes since V1:
* change subject lines of commits to be more specific
* add parameter feature_split_event_channels for xen-netback
* remove two dev_info

Wei Liu (3):
  xen-netback: split event channels support for Xen backend driver
  xen-netfront: split event channels support for Xen frontend driver
  xen: netif.h: document feature-split-event-channels

 drivers/net/xen-netback/common.h    |   13 ++-
 drivers/net/xen-netback/interface.c |   85 ++++

Re: [PATCH] bridge: Set vlan_features to allow offloads on vlans.

Ben Hutchings — 2013-05-22T16:12:44

I think you need to mask out NETIF_F_HW_VLAN_CTAG_TX (although maybe the
vlan driver should take care of that itself).

Ben.

Re: [Patch net-next v8 02/11] ipv6: make ip6_dst_hoplimit() static inline

Mike Rapoport — 2013-05-22T16:10:14

I've lost you here... Why not just:

static inline
bool vxlan_addr_equal(const union vxlan_addr *a, const union vxlan_addr *b)
{
       if (a->sa.sa_family != b->sa.sa_family)
               return false;
       if (a->sa.sa_family == AF_INET6)
               return ipv6_addr_equal(&a->sin6.sin6_addr, &b->sin6.sin6_addr);
       else
               return a->sin.sin_addr.s_addr == b->sin.sin_addr.s_addr;
}

--
Sincrely yours,
Mike.

Re: [PATCH net-next 1/4] bnx2x: Add Private Flags Support

Ben Hutchings — 2013-05-22T16:08:17

[...]
[...]
[...]

No trailing spaces, please.  If you don't like the way private flags are
printed by ethtool, send a patch for ethtool.

Ben.

Re: [Patch net-next] ipv6: use ipv6_addr_any() helper

Nicolas Dichtel — 2013-05-22T16:06:38

Le 22/05/2013 17:41, Cong Wang a écrit :
Acked-by: Nicolas Dichtel <nicolas.dichtel< at >6wind.com>

Re: Generic interface to make physical port number used by a netdevice available to user space

Ben Hutchings — 2013-05-22T16:04:18

That is what it's for.  Unfortunately it is defined to be 0-based and as
you've seen the default (unknown) value is also 0, creating ambiguity.
(It also seems to be more common for user-facing documentation and
physical labels to use 1-based numbering.)

I wonder whether it would do any harm to make it signed and initialised
it to -1 in alloc_netdev_mqs() would do any harm?  That would make the
unknown case unambiguous.


You're thinking about hybrid guest acceleration?  A combination of PCIe
serial number and port number should work.

Ben.

Re: [Patch net-next v8 02/11] ipv6: make ip6_dst_hoplimit() static inline

Cong Wang — 2013-05-22T16:03:23


----- Original Message -----

I know we can use memcmp(), but comparing 16+ bytes even for IPv4 is not
a good idea, also we have to zalloc() every instance of union vxlan_addr.

[Patch net-next] ipv6: use ipv6_addr_scope() helper

Cong Wang — 2013-05-22T15:52:22

From: Cong Wang <xiyou.wangcong< at >gmail.com>

ipv6_addr_type(&addr)&IPV6_ADDR_SCOPE_MASK could be replaced
by ipv6_addr_scope(), which is slightly faster.

Cc: Hideaki YOSHIFUJI <yoshfuji< at >linux-ipv6.org>
Cc: David S. Miller <davem< at >davemloft.net>
Signed-off-by: Cong Wang <xiyou.wangcong< at >gmail.com>

---
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index d684d23..bceaaa7 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
< at >< at > -1126,8 +1126,7 < at >< at > retry:

 ift = !max_addresses ||
       ipv6_count_addresses(idev) < max_addresses ?
-ipv6_add_addr(idev, &addr, tmp_plen,
-      ipv6_addr_type(&addr)&IPV6_ADDR_SCOPE_MASK,
+ipv6_add_addr(idev, &addr, tmp_plen, ipv6_addr_scope(&addr),
       addr_flags) : NULL;
 if (IS_ERR_OR_NULL(ift)) {
 in6_ifa_put(ifp);

Re: [Xen-devel] [PATCH net-next 2/2] xen-netfront: split event channels feature support

David Vrabel — 2013-05-22T15:52:38

A combination of /proc/interrupts and the xenstore keys.

David

Re: [PATCH net-next V2 1/2] xen-netback: split event channels support for Xen backend driver

Wei Liu — 2013-05-22T15:50:55

Sure, if this makes code better comprehensible.


The failure of reading split event channels doesn't imply a fatal error.
Here the fatal error is trying to read both split event channels and
single event channel and fail.

If people really want to debug this problem, they should look at
xenstore entries instead of relying on this log message.


Wei.

Re: [Patch net-next v8 02/11] ipv6: make ip6_dst_hoplimit() static inline

Mike Rapoport — 2013-05-22T15:50:22

I think you can just drop #ifdefs in 90% of the cases rather than
create two versions of code for IPv4 and IPv6....




--
Sincerely yours,
Mike.

[PATCH] bridge: Set vlan_features to allow offloads on vlans.

Vlad Yasevich — 2013-05-22T15:46:30

When vlan device is configured on top of the brige, it does
not support any offload capabilities because the bridge
device does not initiliaze vlan_fatures.  Set vlan_fatures to
be equivalent to hw_fatures.

Signed-off-by: Vlad Yasevich <vyasevic< at >redhat.com>
---
 net/bridge/br_device.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index 9673128..126f2c2 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
< at >< at > -352,6 +352,7 < at >< at > void br_dev_setup(struct net_device *dev)
 dev->hw_features = NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_HIGHDMA |
    NETIF_F_GSO_MASK | NETIF_F_HW_CSUM |
    NETIF_F_HW_VLAN_CTAG_TX;
+dev->vlan_features = dev->hw_features;
 
 br->dev = dev;
 spin_lock_init(&br->lock);