From: Roland Dreier <rol...@purestorage.com>
We need to check if p_ent->comp_mode is QED_SPQ_MODE_EBLOCK before
calling qed_spq_add_entry(). The test is fine is the mode is EBLOCK,
but if it isn't then qed_spq_add_entry() might kfree(p_ent).
Signed-off-by: Roland Dreier <rol...@pur
> I think the conclusion is that a hard-wired ACS capability is a
> positive indication of isolation for a multifunction device, the code
> is intended to support this and appears to do so, and Roland was going
> to investigate the sightings that inspired this patch in more detail.
> Dropping for
> Is there a misunderstanding of the code flow here? We're never setting
> EC. In the first code block we're just masking out requested
> capabilities where unimplemented capabilities is the same as
> implemented + enabled. We're not adding EC to the request, we're
> just not removing it based
> I think that the device implementing ACS and not implementing certain
> features that are "must be implemented if..." is a positive indication
> that the device does not have that behavior and therefore the ability
> to control that behavior is unnecessary. pci_acs_flags_enabled() is
> coded
On Thu, Jul 20, 2017 at 3:15 PM, Alex Williamson
wrote:
> Most of the ACS capabilities are worded as "Must be implemented by
> devices that implement ..." Shouldn't a hard-wired ACS capability
> sufficiently describe that, or is there something wrong with how
>
From: Roland Dreier <rol...@purestorage.com>
Add one more variant of the 82599 plus the device IDs for X540 and X550
variants. Intel has confirmed that none of these devices does peer-to-peer
between functions. The X540 and X550 have added ACS capabilities in their
PCI config space, but t
On Fri, Jul 8, 2016 at 9:51 AM, Jason Gunthorpe
wrote:
> So, it appears, the dst and neigh can be used for all performances cases.
>
> For the non performance dst == null case, can we just burn cycles and
> stuff the daddr in front of the packet at hardheader
On Thu, Jul 7, 2016 at 4:14 PM, Jason Gunthorpe
wrote:
> We have neighbour_priv, and ndo_neigh_construct/destruct now ..
>
> A first blush that would seem to be enough to let ipoib store the AH
> and other path information in the neigh and avoid the cb? At least
>> struct skb_gso_cb {
>> int mac_offset;
>> int encap_level;
>> __u16 csum_start;
>> };
> This is based on an out-dated version of this struct. The 4.7 RC
> kernel has a few more fields that were added to support local checksum
> offload for encapsulated
On Thu, Jan 7, 2016 at 3:00 AM, Konstantin Khlebnikov wrote:
> Or just shift GSO CB and add couple checks like
> BUILD_BUG_ON(sizeof(SKB_GSO_CB(skb)->room) < sizeof(*IPCB(skb)));
Resurrecting this old thread, because the patch that ultimately went
upstream (commit 9207f9d45b0a
From: Roland Dreier <rol...@purestorage.com>
Backports of 41fc014332d9 ("fib_rules: fix fib rule dumps across
multiple skbs") introduced a regression in "ip rule show" - it ends up
dumping the first rule over and over and never exiting, because 3.19
and earlier are m
On Tue, Sep 22, 2015 at 9:40 PM, Roopa Prabhu wrote:
> + err = fib_nl_fill_rule(skb, rule, NETLINK_CB(cb->skb).portid,
> + cb->nlh->nlmsg_seq, RTM_NEWRULE,
> + NLM_F_MULTI, ops);
> +
Thanks, applied, although I assume based on the Signed-off-by line
that you left out a
From: Bryan Rosenburg [EMAIL PROTECTED]
at the top (to get the authorship in git correctly).
RDMA/cxgb3: Shift calculation wrong for single sge entries.
BTW, there's no need to duplicate the subject line
and there were no problems with undefined symbols.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
diff --git a/drivers/net/wireless/libertas/cmd.c
b/drivers/net/wireless/libertas/cmd.c
index eab0203..b3c1acb 100644
--- a/drivers/net/wireless/libertas/cmd.c
+++ b/drivers/net/wireless/libertas/cmd.c
how can a static void function return 0?
good question... I've fixed the patch in my tree.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
loopback connections
The cxgb3 HW and driver don't support loopback RDMA connections. So
fail any connection attempt where the destination address is local.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
diff --git a/drivers
, so this is not
run-tested, but I tested the build with
CONFIG_LIBERTAS=y
CONFIG_LIBERTAS_USB=m
CONFIG_LIBERTAS_CS=m
CONFIG_LIBERTAS_SDIO=m
and there were no problems with undefined symbols.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
Here's the patch that removes the unused
applied, although:
+static void is_loopback_dst(struct iw_cm_id *cm_id)
+{
+struct net_device *dev;
+
+dev = ip_dev_find(init_net, cm_id-remote_addr.sin_addr.s_addr);
+if (!dev)
+return 0;
+dev_put(dev);
+return 1;
+}
is there any way this
thanks, just merged the same patch from Olof Johansson.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
conflict
Therefore, remove the static marking on lbs_remove_mesh and lbs_add_mesh.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
diff --git a/drivers/net/wireless/libertas/main.c
b/drivers/net/wireless/libertas/main.c
index 84fb49c..a688ce8 100644
--- a/drivers/net/wireless/libertas/main.c
Why not pull the exports? they aren't used anywhere in the existing kernel.
I'm guessing there's some not-(yet-)merged mesh networking stuff that
uses the symbols, but it doesn't matter much to me...
- R.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a
On a 2GB Core2 system here I see a time cat /proc/net/tcp /dev/null
constently dropping from 0.44s to 0.4-0.8s system time with this change.
Seems like there must be a typo in either the before or after times
you report here?
--
To unsubscribe from this list: send the line unsubscribe netdev
that it calls, which fixes
WARNING: drivers/net/cxgb3/built-in.o(.text+0x2427): Section mismatch in
reference from the function t3_io_slot_reset() to the function
.devinit.text:t3_prep_adapter()
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
drivers/net/cxgb3/mc5.c |2 +-
drivers/net
thanks, applied.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
thanks, applied 1-3
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-off-by: Roland Dreier [EMAIL PROTECTED]
---
drivers/infiniband/core/cma.c |4 +---
drivers/infiniband/ulp/ipoib/ipoib_multicast.c |4
include/net/if_inet6.h | 11 +++
include/net/ip.h | 10
Commit 70eba18b (make bnx2x select ZLIB_INFLATE) in Linus's tree
seems bogus. As far as I can tell, bnx2x is not upstream yet, and the
commit in question actually adds select ZLIB_INFLATE to the TEHUTI
config, since there is no BNX2X config option (and also I don't see
any reference to zlib in
- skb = netdev_alloc_skb(lro_mgr-dev, hlen);
+ skb = netdev_alloc_skb(lro_mgr-dev, hlen + NET_IP_ALIGN);
NET_IP_ALIGN should only be used if you're DMAing into the skb head.
Otherwise you should say 2. It would be nice to have another macro
for that I suppose.
It
OK, applied 1 and 2...
Note: this change requires 5.0 firmware.
I assume the change to the cxgb3 FW versions is pending in a net
driver change for 2.6.25?
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Agreed. On first glance, I was intrigued but:
1) Why is everyone so concerned that export symbol space is large?
- does it cost cpu or running memory?
- does it cause bugs?
- or are you just worried about evil modules?
2) These aren't real namespaces
- all
This patch allows to export symbols only for specific modules by
introducing symbol name spaces. A module name space has a white
list of modules that are allowed to import symbols for it; all others
can't use the symbols.
It adds two new macros:
Yes, and if a symbol is already used by multiple modules, it's generically
useful. And if so, why restrict it to in-tree modules?
I agree that we shouldn't make things too hard for out-of-tree
modules, but I disagree with your first statement: there clearly is a
large class of symbols that
I agree that we shouldn't make things too hard for out-of-tree
modules, but I disagree with your first statement: there clearly is a
large class of symbols that are used by multiple modules but which are
not generically useful -- they are only useful by a certain small class
of
Except C doesn't have namespaces and this mechanism doesn't create them. So
this is just complete and utter makework; as I said before, noone's going to
confuse all those udp_* functions if they're not in the udp namespace.
I don't understand why you're so opposed to organizing the
thanks, applied.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
+/* TODO: deal with EEPROM endian issues */
This is pretty scary. Is the driver broken on big-endian systems now?
+/*
+Everything you wanted to know about CRC algorithms, but were afraid to ask
+ for fear that errors in your understanding might be detected. Version :
3.
etc
+/**
+ * nes_post_send
+ */
+static int nes_post_send(struct ib_qp *ibqp, struct ib_send_wr *ib_wr,
+struct ib_send_wr **bad_wr)
...
+switch (ib_wr-opcode) {
...
+if (ib_wr-num_sge
Thanks Roland. Let me know when you have your branch ready.
OK, I pushed out a neteffect branch at
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
This has the driver from your git tree plus some compile fixes and
cleanups (added as separate commits, so you can see
OK, a couple quick review comments and a process comment too:
- First step in the driver is to kill off a lot of the #ifdefs:
+#ifdef IRQF_SHARED
The upstream driver really shouldn't have compatibility gunk for older
kernels... just make it build against the kernel it's in.
+#ifdef
+
+EXTRA_CFLAGS += -DNES_MINICM
I don't see anyplace NES_MINICM is used. Delete this line?
+
+obj-$(CONFIG_INFINIBAND_NES) += iw_nes.o
+
+iw_nes-objs := nes.o nes_hw.o nes_nic.o nes_utils.o nes_verbs.o nes_cm.o
+
Also the file has an extra blank line at the beginning and end.
Thanks... I am kind of overloaded trying to handle the last few things
for the 2.6.24 merge window, but I will look at this next week, and I
expect we should be able to merge the driver for 2.6.25 unless there
are unexpected hangups.
-
To unsubscribe from this list: send the line unsubscribe
You are starting off on the wrong foot.
???
+if(!(expr)) {
\
+ printk(KERN_ERR PFX Assertion failed! %s, %s, %s, line %d\n, \
+ #expr, __FILE__, __FUNCTION__,
+static void __iomem *mv643xx_eth_base;
+return readl(((void __iomem *)mv643xx_eth_base) + offset);
Given the declaration of mv643xx_eth_base as void __iomem * already, I
don't understand why you need the cast to the same type here (and
elsewhere in the driver).
- R.
-
To unsubscribe
The bonding sources have a few occurrences of EOPNOTSUPP. Unless I
missed something, they are all related to setting the hardware address
of the interface. AFAICS this is impossible with IP over FireWire. If
it is crucial to bonding to be able to change the slaves' hardware
addresses,
It happens only when ib interfaces are slaves of a bonding device.
I thought before that the stuck is in napi_disable() but it's almost right.
I put prints before and after call to napi_disable and see that it is called
twice.
I'll try to investigate in this direction.
ib0:
I also ran a test for the code in the branch of 2.6.24 and found a problem.
I see that ifconfig down doesn't return (for IPoIB interfaces) and it's
stuck in napi_disable() in the kernel (any idea why?)
For what it's worth, I took the upstream 2.6.23 git tree and merged in
Dave's latest
I'd say we can probably try to get rid of it in 2.6.25, this is
assuming we get driver authors to cooperate and do the conversions
or alternatively some other motivated person.
I can just threaten to do them all and that should get the driver
maintainers going :-)
I can definitely
Before you add new entries to your list, how is that ibm driver NAPI
conversion coming along? :-)
I still haven't done much. OK, I will try to get my board booting
again this week.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
Before you add new entries to your list, how is that ibm driver NAPI
conversion coming along? :-)
OK, thanks for the kick in the pants, I have a couple of patches for
net-2.6.24 coming (including an unrelated trivial warning fix for
IPoIB).
- R.
-
To unsubscribe from this list: send the
structures for a single net_device.
Tested with the internal MAC of a PowerPC 440SPe SoC with an AMCC
'Yucca' evaluation board.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
drivers/net/ibm_emac/ibm_emac_mal.c | 48 --
drivers/net/ibm_emac/ibm_emac_mal.h
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
drivers/net/ibm_newemac/core.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index ce127b9..8ea5009 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b
multiple NAPI structures for a single net_device.
Compile-tested only as I don't have a system that uses the ibm_newemac
driver. This conversion the conversion for the ibm_emac driver that
was tested on real PowerPC 440SPe hardware.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
drivers/net
Sorry... wrong subject here; it should have been ibm_newemac: ...
- R.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
I tested this by simulating a slow passive side responder, and it worked as
expected for those tests. Using an MRA does add another MAD to the CM
exchange,
which is why it is sent only after seeing a duplicate request.
Alternatively,
we can take the OFED module parameter patch.
I'm running 2.6.23-rc9 on my laptop, and when in a coffee shop I use
a Verizon EVDO card to get network access. This is a kyocera device
that looks like a serial adapter behind an ohci usb controller, and
uses the airprime driver (for usb device 0c88:17da). The actual IP
networking is ppp over
I don't want to jump the gun on the analysis but it just might
be the packet sharing fixes Herbert put in a short time ago.
What you could do is go back to say rc2 and see if you still get
the panics, then bisect from there to narrow it down.
If rc2 still gives the panic, it's
Programming with assertions (and BUG_ON is a form of that) is
generally a good practice. Almost any book or other source on
good programming practices will agree. Yes, it can be overdone.
But I don't really think that is the case here, since the check is
relatively inexpensive and the
Just as a quick update -- I seem to only be able to reproduce this
crash when my ppp session drops, which seems associated with marginal
signal. And unfortunately I have great coverage at home so I haven't
been able to reproduce this again today. Maybe on the train tomorrow
I can crash my
OK -- just to make sure I'm understanding what you're saying: have you
confirmed that your proposed [CM MRA] patches actually fix the issue?
Not directly. I cannot easily test kernel patches on our larger, production
clusters. We've seen the issue with specific applications on 512 and
It would be really great to see numbers with a more recent kernel
than 2.6.18
FWIW Debian has binaries for 2.6.21 in testing and for 2.6.22 in
unstable so it should be very easy for Larry to try at least those.
- R.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the
Use the stats member of struct netdevice in IPoIB, so we can save
memory by deleting the stats member of struct ipoib_dev_priv, and save
code by deleting ipoib_get_stats().
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
Dave, can you queue this in net-2.6.24 please? I would ordinarily
merge
How is that ibm_emac NAPI conversion coming along? :-)
Sorry, trying to reduce my backlog first, but it is still on my list
of things to work on :)
- R.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Roland, are you comfortable with the IB changes in patches 1 and 2?
Yes, they look fine to me. Feel free to apply, with
Acked-by: Roland Dreier [EMAIL PROTECTED]
- R.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More
The action in bonding to a detach of slave is to unregister the master (see
patch 10).
This can't be done from the context of unregister_netdevice itself (it is
protected by rtnl_lock).
I'm confused. Your patch has:
+ipoib_slave_detach(cpriv-dev);
Just change the makefiles to always install gzip'ed modules
modutils knows how to unzip them on the fly.
But that leaves the uncompressed firmware blobs in .data that ends up
in unswappable kernel memory.
- R.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of
+ipoib_slave_detach(cpriv-dev);
unregister_netdev(cpriv-dev);
Maybe you already answered this before, but I'm still not clear why
this notifier call can't just be added to the start of
unregister_netdevice(), so we can avoid having driver needing to know
anything
Roland - can you please queue this up for 2.6.24?
Done, thanks.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
One other thing I observed is that I can not unload the module as the
ref counter of the eth device is too low. I haven't tracked down the
source of this problem yet.
I suspect that this is because netif_rx_reschedule() was missing a
dev_hold() to match the dev_put() in
Thanks for the patch...
If an application is calling rdma_resolve_ip() and a status of -ENODATA is
returned from addr_resolve_local/remote(), the timeout mechanism waits until
the application's timeout occurs before rechecking the address resolution
status; the application will wait
I think that if there are no other comments, I will submit the entire 11
patches
again (with changes) to make it easier to merge into the kernel. Since the
most of the
content in the patch series is in bonding I thought it would be right that
Jay will
push all the patches to
Thanks for testing on ehca...
While using IPoIB over EHCA (rc6 bits), unregister_netdev hangs with
I don't think you're actually using rc6 bits, since in your patch you have:
-poll_more:
and I think that is only in Dave's net-2.6.24 tree now, right?
The problem is that the poll handler
Roland, could you merge the common TX CQ patch please?
It actually fixes a real problem.
Yes, I will, but it collides with the net-2.6.24 NAPI rework I think,
so it may not go in until a few days after the merge window.
Have you verified that the patch cures the interrupt overload issues?
-
Maybe this new notification function should be in net/core/dev.c
instead of exporting call_netdevice_notifiers()?
Or actually, does it work to add the call to the notifiers directly in
unregister_netdev() so that device drivers don't have to worry about it?
(And is the existing patch missing
It looks like the comments for dev_put() and dev_hold() got reversed somehow.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
include/linux/netdevice.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index
by Krishna Kumar
[EMAIL PROTECTED] with IPoIB waiting forever for netdev refcounts
to become 0 during module unload.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
Dave, feel free to roll this up into earlier NAPI conversion patches
(assuming I'm understanding things correctly and this patch
Further complicating things is that you need to setup a ppc32
cross-build environment to even build test a conversion, and I'm not
comfortable doing the surgery until I can test build the thing.
OK, I actually have a system with a ppc 440 SoC that uses this driver,
so I'll try to get things
and I think that is only in Dave's net-2.6.24 tree now, right?
Nope, that was what I downloaded yesterday:
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 23
EXTRAVERSION =-rc6
NAME = Pink Farting Weasel
Please double check your tree. I just very carefully looked at my
trees, and the
IPoIB CM handles this properly by gathering together single pages in
skbs' fragment lists.
Then can we reuse IPoIB CM code here?
Yes, if possible, refactoring things so that the rx skb allocation
code becomes common between CM and non-CM would definitely make sense.
-
To unsubscribe from
The IGMP enabling patch posted by me on September 2nd isn't on your list
http://lists.openfabrics.org/pipermail/general/2007-September/040250.html
can you add it?
Yes, I lost that somehow. I will add it to my list of things to take
a look at (no opinion yet).
- R.
-
To unsubscribe from
I tried to look at the ipoib stuff in this series... this patch looks
fine but it doesn't actually touch ipoib, so the subject line is a bit
misleading...
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Looks fine overall, with one minor nitpick:
-if (unlikely(memcmp(neigh-dgid.raw,
+if (unlikely((memcmp(neigh-dgid.raw,
skb-dst-neighbour-ha + 4,
-sizeof(union
Actually, thinking about this some more... would it be cleaner to more
the knowledge about bonding out of the ipoib driver? in other words,
export something similar to
+static int ipoib_slave_detach(struct net_device *dev)
+{
+int ret = 0;
+if (dev-flags IFF_SLAVE) {
+
OK with me.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Overall idea looks good... one comment:
+if (n-dev-flags IFF_MASTER) {
+/* n-dev is not an IPoIB device and we have
+to take priv from elsewhere */
+neigh = *to_ipoib_neigh(n);
+if (neigh) {
+priv =
Conceptually, I see your point and I'm ok with doing it either
way. My only question is, would this change would make the ipoib module
dependent upon having the bonding module loaded (to resolve all of the
symbols)?
Yes, I guess so, if that function is in bonding. Hmm, that
Maybe you should automatically create an alias each time new interface
is added so that admin would not care about proper aliases?
I agree that makes much more sense from a user interface point of
view. Unfortunately an alias without an address doesn't make sense,
so there doesn't seem to be
The patch is just needed to pick up broadcast MTU size instead of hard
coding 2K right now. SKB allocation shouldn't be different with Ethernet
Jambo Frame and IPoIB-CM which 64K MTU. I don't understand why it's
different. Could you please explain this?
It's exactly the same problem as
I've been meaning to track down the bnx2 iscsi offload patch to look
and see if this issue is addressed, since the same problem seems to
exist: it seems an iscsi connection and a main stack tcp connection
might share the same 4-tuple unless something is done to avoid that
happening.
IB/mthca: Enable MSI-X by default
Peter Oruba (1):
IB/mthca: Use PCI-X/PCI-Express read control interfaces
Roland Dreier (6):
IPoIB: Make sure no receives are handled when stopping device
IB: find_first_zero_bit() takes unsigned pointer
mlx4_core: Don't free special
Since ehca can support 4K MTU, we would like to see a patch in
IPoIB to allow link MTU to be up to 4K instead of current 2K for 2.6.24
kernel. The idea is IPoIB link MTU will pick up a return value from SM's
default broadcast MTU. This patch should be a small patch, I hope you
- My user_mad P_Key index support patch. I'll test the ioctl to
change to the new mode and merge this I guess, since Hal and Sean
have tested this out.
I can give this patch a reviewed-by: too, and I will also try to review a
couple
of the pending ipoib patches.
Thanks!
I was about to post v2 of my patch to avoid port space collisions with
the native stack. Can we get that 2.6.24? It is high priority
IMO. I've tried to solicit review on it, but I think folks are
reluctant... ;-)
I would like to get this in, but I'm still at least a little
reluctant,
Well, if it involves /sharing/ port space with the native stack,
i.e. where port 1234 is IB but 1235 is Linux, pretty much all the
networking devs have NAK'd that approach AFAICS.
Just to be clear, InfiniBand has no problem; the issue is port
collisions involving iWARP connections.
- R.
-
What's wrong with my suggestion of having the iwarp driver create an
iwX interface to go with the normal ethX interface? It seems
simpler to me, and there's a somewhat similar precedent with how
mac80211 devices create both wlan0 and wmaster0 interfaces.
- R.
It seemed much
The sysadmin creates for iwarp use only alias interfaces of the form
devname:iw* where devname is the native interface name (eg eth0) for the
iwarp netdev device. The alias label can be anything starting with iw.
The iw immediately after the ':' is the key used by the iwarp driver.
Sorry for the long latency, I was at the beach all last week.
And direct data placement really does give you a factor of two at
least, because otherwise you're stuck receiving the data in one
buffer, looking at some of the data at least, and then figuring out
where to copy it. And
I take that back. Rejected -- it breaks infiniband build.
To be more precise:
drivers/infiniband/hw/cxgb3/cxio_hal.c: In function 'cxio_rdev_open':
drivers/infiniband/hw/cxgb3/cxio_hal.c:919: error: implicit declaration of
function 'T3CDEV'
it seems the problem is that T3CDEV() has
Looks OK to me but I would just roll up the second patch into the
first patch and let Jeff merge it as one commit. There's no point in
creating an intermediate tree that doesn't build -- it just breaks git
bisect for no useful purpose.
Also as a side note, when trying to test this I got the
[TSO / LRO discussion snipped -- it's not the main point so no sense
spending energy arguing about it]
Just be realistic and accept that RDMA is a point in time solution,
and like any other such technology takes flexibility away from users.
Horizontal scaling of cpus up to huge arity
Isn't RDMA _part_ of the software net stack within Linux?
It very much is not so.
This is just nit-picking. You can draw the boundary of the software
net stack wherever you want, but I think Sean's point was just that
RDMA drivers already are part of Linux, and we all want them to get
1 - 100 of 288 matches
Mail list logo