> now that you put it that way, I get the merit of what you are saying.
> Very well. I will submit the first set of patches.
>
> May I add your "Tested-by"?
Yes, absolutely:
Tested-by: Roland Dreier
> > to preserve the legacy behavior rather than changing the behavior of
> > every usbnet driver all at once? Like make a new
> > usbnet_get_link_ksettings_nonmdio and update only cdc_ncm to use it?
>
> Then I would have to touch them all. The problem is that the MDIO
> stuff really is pretty much
I haven't tried these patches yet but they don't look quite right to
me. inlining the first 0001 patch:
> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> index 1447da1d5729..bcd17f6d6de6 100644
> --- a/drivers/net/usb/usbnet.c
> +++ b/drivers/net/usb/usbnet.c
> @@ -944,7 +
> I looked at them again and found that there is a way to get
> the same effect that will make maintenance easier in the long run.
> Could I send them to you later this week for testing?
Yes, please. I have a good test setup now so I can easily try out patches.
Thanks,
Roland
> Applied to net and queued for LTS, thanks!
Thanks - is Oliver's series of 3 patches that get rid of the other
half of the log spam also on the way upstream?
- R.
m spamming the kernel log with
cdc_ncm 2-2:2.0 enp0s2u2c2: network connection: connected
messages every 60 msec or so.
Signed-off-by: Roland Dreier
---
drivers/net/usb/cdc_ncm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_n
On Tue, Dec 22, 2020 at 6:49 PM Jakub Kicinski wrote:
> I'm not sure what the story here is but if this change is expected to
> get into the networking tree we'll need a fresh posting. This sort of
> scissored reply does not get into patchwork.
OK, will resend. Too bad about patchwork, "git am"
[ 30.086548] cdc_ncm 2-2:2.0 enp0s2u2c2: network connection: connected
with the below patch on top of your 3, then my kernel log is clean.
Please apply your patches plus my patch, and feel free to add
Tested-by: Roland Dreier
to the other three.
--- 8< -- 8< ---
Subject: [PATCH] CDC-NCM:
> your criticism was valid. Could you test the attached patches?
Thanks - I will build a kernel and report back.
- R.
Hi, I recently got a 2.5G USB adapter, and although it works fine, the
driver continually spams the kernel log with messages like
[127662.025647] cdc_ncm 4-1:2.0 enx3c8cf8f942e0: network connection: connected
[127662.057680] cdc_ncm 4-1:2.0 enx3c8cf8f942e0: 2500 mbit/s downlink
2500 mbit/s uplink
From: Roland Dreier
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
---
drivers/net/ethernet/qlogic/qed/q
> 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 n
> 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 o
> 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 wit
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
> they're hard wired?
Interesting q
From: Roland Dreier
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 the ACS control register is
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 time, even if we
> have to copy?
OK,
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 the
> example in clip sure looks li
>> 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 frames.
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 / net: preserve IP
From: Roland Dreier
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 missing commit 053c095a82cf (&quo
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);
> + if (err)
FWI
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 li
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/lib
: Fail 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]>
> 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
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 an
dware, 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
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
> 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 me
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/
> 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 net
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 +-
d
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
MAIL PROTECTED]>
Signed-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
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 suppo
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 h
> 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
>
> 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 ker
> > 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
>
> 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
> 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:
>
> MODULE_NAMESPACE_ALLOW(na
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
> +/**
> + * 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 >
> nesdev->nes
> +/* 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.
e
> 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 OFED_
> +config INFINIBAND_NES_DEBUG
> +bool "Verbose debugging output"
> +depends on INFINIBAND_NES
> +default n
> +---help---
> + This option causes the NetEffect RNIC driver to produce debug
> + messages. Select this if you are developing the driver
> + or tryin
> +
> +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 en
> You are starting off on the wrong foot.
???
> > +if(!(expr)) {
> > \
> > + printk(KERN_ERR PFX "Assertion failed! %s, %s, %s, line %d\n", \
> > + #expr, __FILE__, __FU
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 netde
> +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
> addres
> 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: s
> 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 n
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
ts to have 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]
The conversion to use netdevice internal stats left an unused variable
in ipoib_neigh_free(), since there's no longer any reason to get
netdev_priv() in order to increment dropped packets. Delete the
unused priv variable.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
drivers
e multiple NAPI 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 --
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
> 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 li
> 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 PROTECT
> 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 definite
> 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
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 laptop.
> 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
> 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'
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 th
> 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
> >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 5
> 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 ht
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 ordi
> 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
> 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);
> un
> 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
> 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
> +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 a
> 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
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
> 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 netif_rx_complete
> > 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,
> 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 thin
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
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 correct
> 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 missin
> 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?
-
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 handle
> 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 woul
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) {
> +pri
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
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) {
> +
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
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 http:/
> 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
> > 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
> > 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
> > h
> 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
> 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 b
1 - 100 of 309 matches
Mail list logo
