* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Michael S. Tsirkin @ 2012-08-12 20:54 UTC (permalink / raw)
To: Or Gerlitz
Cc: Eric W. Biederman, davem, roland, netdev, ali, sean.hefty,
Erez Shitrit, Doug Ledford
In-Reply-To: <5027BA17.6010503@mellanox.com>
On Sun, Aug 12, 2012 at 05:13:43PM +0300, Or Gerlitz wrote:
> On 12/08/2012 16:55, Michael S. Tsirkin wrote:
> >I didn't realize you do ARP snooping. Why? I know you mangle
> >outgoing ARP packets,
>
> Maybe I wasn't accurate/clear, we do mangle outgoing/incoming ARP
> packets, from/to Ethernet ARPs
> to/from IPoIB ARPs.
>
>
> >this will go away if you maintain a mapping in SM accessible to
> >all guests.
>
> guests don't interact with IB, I assume you referred to dom0 code, eIPoIB or
> another driver in the host. But what mapping exactly?
Well we are getting into protocol design here. So here's a sketch
showing how you could build a protocol that does work. But note it is
not *exactly* IPoIB. It is I think close enough that you can
use existing NIC hardware/firmware, which is why it
differs slightly from what Eric described, and is
more complex. But it still shares the same property of no hacks, no
packet snooping in driver, etc.
And if you want to go that route, you really should talk to some IB
protocol people to figure out what works, write a spec and try to
standardize. lkml/netdev is not the right place.
But since you asked, if I had to, I would probably try to
do it like this:
- Each device registers with the SA specifying the
mac address (+ vlan?), SA stores the translation from that
to IPoIB address.
- alternatively, SA admin configures the translation statically
- you get a packet with 6 byte mac address,
query the SA for a mapping to IPoIB address, strip
ethernet frame and send
- multicast GID addresses can be similar, filled either when registering
for multicast or by SA admin
I think it's possible that you could also convert a mac address to
EUI-64 and prepend a prefix to get a legal GID. But maybe I'm missing
something. This could be handy for multicast.
In both cases:
- SA could return GID that you then resolve to
LID using another query, or it could return LID so you save a roundtrip
- results can be cached locally
- SA can send updates when translation changes to flush this cache
Now above means protocols such as ARP and DHCP use 48 bit addresses so
you can not mix this new protocol with IPoIB. Maybe IPoIB could simply
ignore irrelevant packets, but it's best not to try, get a
different all-broadcast group and CM ID instead to avoid confusion.
One other interesting thing you can do is forward multicast
registration data from the router, translate to mgid
by the SA and do appropriate IB mcast registrations.
My memory of how IB works is a bit rusty so I probably made some
mistakes above but should roughly work, I think.
> and remember that
> this code (VM through eipoib) can talk to any IPoIB element on the
> fabric, native,
> virtualized, HW/SW gateways, etc etc.
>
> Or.
If you want this, then you really want a limited form of IPoIB bridging.
Alternatively, decide that what you do is not IPoIB, have a proper
protocol of your own.
--
MST
^ permalink raw reply
* Re: [PATCH net-next] af_packet: remove BUG statement in tpacket_destruct_skb
From: David Miller @ 2012-08-12 20:42 UTC (permalink / raw)
To: danborkmann; +Cc: netdev
In-Reply-To: <1344674934.16015.3.camel@thinkbox>
From: Daniel Borkmann <danborkmann@iogearbox.net>
Date: Sat, 11 Aug 2012 10:48:54 +0200
> Here's a quote of the comment about the BUG macro from asm-generic/bug.h:
>
> Don't use BUG() or BUG_ON() unless there's really no way out; one
> example might be detecting data structure corruption in the middle
> of an operation that can't be backed out of. If the (sub)system
> can somehow continue operating, perhaps with reduced functionality,
> it's probably not BUG-worthy.
>
> If you're tempted to BUG(), think again: is completely giving up
> really the *only* solution? There are usually better options, where
> users don't need to reboot ASAP and can mostly shut down cleanly.
>
> In our case, the status flag of a ring buffer slot is managed from both sides,
> the kernel space and the user space. This means that even though the kernel
> side might work as expected, the user space screws up and changes this flag
> right between the send(2) is triggered when the flag is changed to
> TP_STATUS_SENDING and a given skb is destructed after some time. Then, this
> will hit the BUG macro. As David suggested, the best solution is to simply
> remove this statement since it cannot be used for kernel side internal
> consistency checks. I've tested it and the system still behaves /stable/ in
> this case, so in accordance with the above comment, we should rather remove it.
>
> Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH] bnx2x: Fix compiler warnings
From: David Miller @ 2012-08-12 20:42 UTC (permalink / raw)
To: yuvalmin; +Cc: joren.vanonder, eilong, netdev, linux-kernel
In-Reply-To: <50273628.50503@broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Sun, 12 Aug 2012 07:50:48 +0300
>> Fix the following compiler warnings:
>>
>> - drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:2908:3: warning: comparison
>> of distinct pointer types lacks a cast [enabled by default]
>> - drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c:1709:7: warning: comparison
>> of distinct pointer types lacks a cast [enabled by default]
>>
>> Signed-off-by: Joren Van Onder <joren.vanonder@gmail.com>
> Thanks Joren.
> Acked-By: Yuval Mintz <yuvalmin@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] macvtap: rcu_dereference outside read-lock section
From: David Miller @ 2012-08-12 20:41 UTC (permalink / raw)
To: mst
Cc: yefremov.denis, jasowang, ebiederm, ian.campbell, netdev,
linux-kernel, ldv-project
In-Reply-To: <20120812084929.GB4430@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Sun, 12 Aug 2012 11:49:29 +0300
> On Sun, Aug 12, 2012 at 10:26:31AM +0400, Denis Efremov wrote:
>> rcu_dereference occurs in update section. Replacement by
>> rcu_dereference_protected in order to prevent lockdep
>> complaint.
>>
>> Found by Linux Driver Verification project (linuxtesting.org)
>>
>> Signed-off-by: Denis Efremov <yefremov.denis@gmail.com>
...
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net] net: sierra_net: replace whitelist with ifnumber match
From: David Miller @ 2012-08-12 20:40 UTC (permalink / raw)
To: bjorn-yOkvZcmFvRU
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1344801218-11041-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Date: Sun, 12 Aug 2012 21:53:38 +0200
> Please apply to "net".
Simplifications and cleanups are not appropriate for the 'net'
tree.
I would say that all of the patches you posted today are
'net-next' material.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net] net: sierra_net: replace whitelist with ifnumber match
From: Bjørn Mork @ 2012-08-12 19:53 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, Bjørn Mork
Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
---
This driver can also be simplified by using the new interface number
matching, avoiding unnecessary probing of unsupported interfaces at
the same time.
Please apply to "net".
drivers/net/usb/sierra_net.c | 52 ++++++++++--------------------------------
1 file changed, 12 insertions(+), 40 deletions(-)
diff --git a/drivers/net/usb/sierra_net.c b/drivers/net/usb/sierra_net.c
index d75d1f5..7be49ea 100644
--- a/drivers/net/usb/sierra_net.c
+++ b/drivers/net/usb/sierra_net.c
@@ -68,15 +68,8 @@ static atomic_t iface_counter = ATOMIC_INIT(0);
*/
#define SIERRA_NET_USBCTL_BUF_LEN 1024
-/* list of interface numbers - used for constructing interface lists */
-struct sierra_net_iface_info {
- const u32 infolen; /* number of interface numbers on list */
- const u8 *ifaceinfo; /* pointer to the array holding the numbers */
-};
-
struct sierra_net_info_data {
u16 rx_urb_size;
- struct sierra_net_iface_info whitelist;
};
/* Private data structure */
@@ -637,21 +630,6 @@ static int sierra_net_change_mtu(struct net_device *net, int new_mtu)
return usbnet_change_mtu(net, new_mtu);
}
-static int is_whitelisted(const u8 ifnum,
- const struct sierra_net_iface_info *whitelist)
-{
- if (whitelist) {
- const u8 *list = whitelist->ifaceinfo;
- int i;
-
- for (i = 0; i < whitelist->infolen; i++) {
- if (list[i] == ifnum)
- return 1;
- }
- }
- return 0;
-}
-
static int sierra_net_get_fw_attr(struct usbnet *dev, u16 *datap)
{
int result = 0;
@@ -706,11 +684,6 @@ static int sierra_net_bind(struct usbnet *dev, struct usb_interface *intf)
dev_dbg(&dev->udev->dev, "%s", __func__);
ifacenum = intf->cur_altsetting->desc.bInterfaceNumber;
- /* We only accept certain interfaces */
- if (!is_whitelisted(ifacenum, &data->whitelist)) {
- dev_dbg(&dev->udev->dev, "Ignoring interface: %d", ifacenum);
- return -ENODEV;
- }
numendpoints = intf->cur_altsetting->desc.bNumEndpoints;
/* We have three endpoints, bulk in and out, and a status */
if (numendpoints != 3) {
@@ -945,13 +918,8 @@ struct sk_buff *sierra_net_tx_fixup(struct usbnet *dev, struct sk_buff *skb,
return NULL;
}
-static const u8 sierra_net_ifnum_list[] = { 7, 10, 11 };
static const struct sierra_net_info_data sierra_net_info_data_direct_ip = {
.rx_urb_size = 8 * 1024,
- .whitelist = {
- .infolen = ARRAY_SIZE(sierra_net_ifnum_list),
- .ifaceinfo = sierra_net_ifnum_list
- }
};
static const struct driver_info sierra_net_info_direct_ip = {
@@ -965,15 +933,19 @@ static const struct driver_info sierra_net_info_direct_ip = {
.data = (unsigned long)&sierra_net_info_data_direct_ip,
};
+#define DIRECT_IP_DEVICE(vend, prod) \
+ {USB_DEVICE_INTERFACE_NUMBER(vend, prod, 7), \
+ .driver_info = (unsigned long)&sierra_net_info_direct_ip}, \
+ {USB_DEVICE_INTERFACE_NUMBER(vend, prod, 10), \
+ .driver_info = (unsigned long)&sierra_net_info_direct_ip}, \
+ {USB_DEVICE_INTERFACE_NUMBER(vend, prod, 11), \
+ .driver_info = (unsigned long)&sierra_net_info_direct_ip}
+
static const struct usb_device_id products[] = {
- {USB_DEVICE(0x1199, 0x68A3), /* Sierra Wireless USB-to-WWAN modem */
- .driver_info = (unsigned long) &sierra_net_info_direct_ip},
- {USB_DEVICE(0x0F3D, 0x68A3), /* AT&T Direct IP modem */
- .driver_info = (unsigned long) &sierra_net_info_direct_ip},
- {USB_DEVICE(0x1199, 0x68AA), /* Sierra Wireless Direct IP LTE modem */
- .driver_info = (unsigned long) &sierra_net_info_direct_ip},
- {USB_DEVICE(0x0F3D, 0x68AA), /* AT&T Direct IP LTE modem */
- .driver_info = (unsigned long) &sierra_net_info_direct_ip},
+ DIRECT_IP_DEVICE(0x1199, 0x68A3), /* Sierra Wireless USB-to-WWAN modem */
+ DIRECT_IP_DEVICE(0x0F3D, 0x68A3), /* AT&T Direct IP modem */
+ DIRECT_IP_DEVICE(0x1199, 0x68AA), /* Sierra Wireless Direct IP LTE modem */
+ DIRECT_IP_DEVICE(0x0F3D, 0x68AA), /* AT&T Direct IP LTE modem */
{}, /* last item */
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH net 3/3] net: qmi_wwan: compress device_id list using macros
From: Bjørn Mork @ 2012-08-12 19:16 UTC (permalink / raw)
To: netdev; +Cc: linux-usb, Bjørn Mork
In-Reply-To: <1344798992-10176-1-git-send-email-bjorn@mork.no>
Take advantage of the matching macros to make the device id
list easier to read and maintain.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
drivers/net/usb/qmi_wwan.c | 25 ++++---------------------
1 file changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 24524b2..aaa061b 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -356,38 +356,21 @@ static const struct driver_info qmi_wwan_shared = {
static const struct usb_device_id products[] = {
/* 1. CDC ECM like devices match on the control interface */
{ /* Huawei E392, E398 and possibly others sharing both device id and more... */
- .match_flags = USB_DEVICE_ID_MATCH_VENDOR | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = HUAWEI_VENDOR_ID,
- .bInterfaceClass = USB_CLASS_VENDOR_SPEC,
- .bInterfaceSubClass = 1,
- .bInterfaceProtocol = 9, /* CDC Ethernet *control* interface */
+ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 1, 9),
.driver_info = (unsigned long)&qmi_wwan_info,
},
{ /* Vodafone/Huawei K5005 (12d1:14c8) and similar modems */
- .match_flags = USB_DEVICE_ID_MATCH_VENDOR | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = HUAWEI_VENDOR_ID,
- .bInterfaceClass = USB_CLASS_VENDOR_SPEC,
- .bInterfaceSubClass = 1,
- .bInterfaceProtocol = 57, /* CDC Ethernet *control* interface */
+ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 1, 57),
.driver_info = (unsigned long)&qmi_wwan_info,
},
/* 2. Combined interface devices matching on class+protocol */
{ /* Huawei E392, E398 and possibly others in "Windows mode" */
- .match_flags = USB_DEVICE_ID_MATCH_VENDOR | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = HUAWEI_VENDOR_ID,
- .bInterfaceClass = USB_CLASS_VENDOR_SPEC,
- .bInterfaceSubClass = 1,
- .bInterfaceProtocol = 17,
+ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 1, 17),
.driver_info = (unsigned long)&qmi_wwan_shared,
},
{ /* Pantech UML290 */
- .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = 0x106c,
- .idProduct = 0x3718,
- .bInterfaceClass = 0xff,
- .bInterfaceSubClass = 0xf0,
- .bInterfaceProtocol = 0xff,
+ USB_DEVICE_AND_INTERFACE_INFO(0x106c, 0x3718, USB_CLASS_VENDOR_SPEC, 0xf0, 0xff),
.driver_info = (unsigned long)&qmi_wwan_shared,
},
--
1.7.10.4
^ permalink raw reply related
* [PATCH net 1/3] net: qmi_wwan: use fixed interface number matching
From: Bjørn Mork @ 2012-08-12 19:16 UTC (permalink / raw)
To: netdev; +Cc: linux-usb, Bjørn Mork
In-Reply-To: <1344798992-10176-1-git-send-email-bjorn@mork.no>
This driver support many composite USB devices where the
interface class/subclass/protocol provides no information
about the interface function. Interfaces with different
functions may all use ff/ff/ff, like this example of
a device with three serial interfaces and three QMI/wwan
interfaces:
T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=116 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1199 ProdID=68a2 Rev= 0.06
S: Manufacturer=Sierra Wireless, Incorporated
S: Product=MC7710
S: SerialNumber=3581780xxxxxx
C:* #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=qcserial
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=qcserial
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qcserial
E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#=19 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E: Ad=87(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#=20 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=89(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
E: Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
Instead of class/subclass/protocol the vendor use fixed
interface numbers for each function, and the Windows
drivers use these numbers to match driver and function.
The driver has had its own interface number whitelisting
code to simulate this functionality. Replace this with
generic interface number matching now that the USB subsystem
support is there. This
- removes the need for a driver_info structure per
interface number,
- avoids running the probe function for unsupported
interfaces, and
- simplifies the code.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
drivers/net/usb/qmi_wwan.c | 215 ++++++--------------------------------------
1 file changed, 28 insertions(+), 187 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 2ea126a..c6a5873 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -247,30 +247,12 @@ err:
*/
static int qmi_wwan_bind_shared(struct usbnet *dev, struct usb_interface *intf)
{
- int rv;
struct qmi_wwan_state *info = (void *)&dev->data;
- /* ZTE makes devices where the interface descriptors and endpoint
- * configurations of two or more interfaces are identical, even
- * though the functions are completely different. If set, then
- * driver_info->data is a bitmap of acceptable interface numbers
- * allowing us to bind to one such interface without binding to
- * all of them
- */
- if (dev->driver_info->data &&
- !test_bit(intf->cur_altsetting->desc.bInterfaceNumber, &dev->driver_info->data)) {
- dev_info(&intf->dev, "not on our whitelist - ignored");
- rv = -ENODEV;
- goto err;
- }
-
/* control and data is shared */
info->control = intf;
info->data = intf;
- rv = qmi_wwan_register_subdriver(dev);
-
-err:
- return rv;
+ return qmi_wwan_register_subdriver(dev);
}
static void qmi_wwan_unbind(struct usbnet *dev, struct usb_interface *intf)
@@ -356,86 +338,23 @@ static const struct driver_info qmi_wwan_shared = {
.manage_power = qmi_wwan_manage_power,
};
-static const struct driver_info qmi_wwan_force_int0 = {
- .description = "Qualcomm WWAN/QMI device",
- .flags = FLAG_WWAN,
- .bind = qmi_wwan_bind_shared,
- .unbind = qmi_wwan_unbind,
- .manage_power = qmi_wwan_manage_power,
- .data = BIT(0), /* interface whitelist bitmap */
-};
-
-static const struct driver_info qmi_wwan_force_int1 = {
- .description = "Qualcomm WWAN/QMI device",
- .flags = FLAG_WWAN,
- .bind = qmi_wwan_bind_shared,
- .unbind = qmi_wwan_unbind,
- .manage_power = qmi_wwan_manage_power,
- .data = BIT(1), /* interface whitelist bitmap */
-};
-
-static const struct driver_info qmi_wwan_force_int2 = {
- .description = "Qualcomm WWAN/QMI device",
- .flags = FLAG_WWAN,
- .bind = qmi_wwan_bind_shared,
- .unbind = qmi_wwan_unbind,
- .manage_power = qmi_wwan_manage_power,
- .data = BIT(2), /* interface whitelist bitmap */
-};
-
-static const struct driver_info qmi_wwan_force_int3 = {
- .description = "Qualcomm WWAN/QMI device",
- .flags = FLAG_WWAN,
- .bind = qmi_wwan_bind_shared,
- .unbind = qmi_wwan_unbind,
- .manage_power = qmi_wwan_manage_power,
- .data = BIT(3), /* interface whitelist bitmap */
-};
-
-static const struct driver_info qmi_wwan_force_int4 = {
- .description = "Qualcomm WWAN/QMI device",
- .flags = FLAG_WWAN,
- .bind = qmi_wwan_bind_shared,
- .unbind = qmi_wwan_unbind,
- .manage_power = qmi_wwan_manage_power,
- .data = BIT(4), /* interface whitelist bitmap */
-};
-
-/* Sierra Wireless provide equally useless interface descriptors
- * Devices in QMI mode can be switched between two different
- * configurations:
- * a) USB interface #8 is QMI/wwan
- * b) USB interfaces #8, #19 and #20 are QMI/wwan
- *
- * Both configurations provide a number of other interfaces (serial++),
- * some of which have the same endpoint configuration as we expect, so
- * a whitelist or blacklist is necessary.
- *
- * FIXME: The below whitelist should include BIT(20). It does not
- * because I cannot get it to work...
- */
-static const struct driver_info qmi_wwan_sierra = {
- .description = "Sierra Wireless wwan/QMI device",
- .flags = FLAG_WWAN,
- .bind = qmi_wwan_bind_shared,
- .unbind = qmi_wwan_unbind,
- .manage_power = qmi_wwan_manage_power,
- .data = BIT(8) | BIT(19), /* interface whitelist bitmap */
-};
-
#define HUAWEI_VENDOR_ID 0x12D1
+/* map QMI/wwan function by a fixed interface number */
+#define QMI_FIXED_INTF(vend, prod, num) \
+ USB_DEVICE_INTERFACE_NUMBER(vend, prod, num), \
+ .driver_info = (unsigned long)&qmi_wwan_shared
+
/* Gobi 1000 QMI/wwan interface number is 3 according to qcserial */
#define QMI_GOBI1K_DEVICE(vend, prod) \
- USB_DEVICE(vend, prod), \
- .driver_info = (unsigned long)&qmi_wwan_force_int3
+ QMI_FIXED_INTF(vend, prod, 3)
-/* Gobi 2000 and Gobi 3000 QMI/wwan interface number is 0 according to qcserial */
+/* Gobi 2000/3000 QMI/wwan interface number is 0 according to qcserial */
#define QMI_GOBI_DEVICE(vend, prod) \
- USB_DEVICE(vend, prod), \
- .driver_info = (unsigned long)&qmi_wwan_force_int0
+ QMI_FIXED_INTF(vend, prod, 0)
static const struct usb_device_id products[] = {
+ /* 1. CDC ECM like devices match on the control interface */
{ /* Huawei E392, E398 and possibly others sharing both device id and more... */
.match_flags = USB_DEVICE_ID_MATCH_VENDOR | USB_DEVICE_ID_MATCH_INT_INFO,
.idVendor = HUAWEI_VENDOR_ID,
@@ -452,10 +371,9 @@ static const struct usb_device_id products[] = {
.bInterfaceProtocol = 57, /* CDC Ethernet *control* interface */
.driver_info = (unsigned long)&qmi_wwan_info,
},
- { /* Huawei E392, E398 and possibly others in "Windows mode"
- * using a combined control and data interface without any CDC
- * functional descriptors
- */
+
+ /* 2. Combined interface devices matching on class+protocol */
+ { /* Huawei E392, E398 and possibly others in "Windows mode" */
.match_flags = USB_DEVICE_ID_MATCH_VENDOR | USB_DEVICE_ID_MATCH_INT_INFO,
.idVendor = HUAWEI_VENDOR_ID,
.bInterfaceClass = USB_CLASS_VENDOR_SPEC,
@@ -472,98 +390,21 @@ static const struct usb_device_id products[] = {
.bInterfaceProtocol = 0xff,
.driver_info = (unsigned long)&qmi_wwan_shared,
},
- { /* ZTE MF820D */
- .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = 0x19d2,
- .idProduct = 0x0167,
- .bInterfaceClass = 0xff,
- .bInterfaceSubClass = 0xff,
- .bInterfaceProtocol = 0xff,
- .driver_info = (unsigned long)&qmi_wwan_force_int4,
- },
- { /* ZTE MF821D */
- .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = 0x19d2,
- .idProduct = 0x0326,
- .bInterfaceClass = 0xff,
- .bInterfaceSubClass = 0xff,
- .bInterfaceProtocol = 0xff,
- .driver_info = (unsigned long)&qmi_wwan_force_int4,
- },
- { /* ZTE (Vodafone) K3520-Z */
- .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = 0x19d2,
- .idProduct = 0x0055,
- .bInterfaceClass = 0xff,
- .bInterfaceSubClass = 0xff,
- .bInterfaceProtocol = 0xff,
- .driver_info = (unsigned long)&qmi_wwan_force_int1,
- },
- { /* ZTE (Vodafone) K3565-Z */
- .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = 0x19d2,
- .idProduct = 0x0063,
- .bInterfaceClass = 0xff,
- .bInterfaceSubClass = 0xff,
- .bInterfaceProtocol = 0xff,
- .driver_info = (unsigned long)&qmi_wwan_force_int4,
- },
- { /* ZTE (Vodafone) K3570-Z */
- .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = 0x19d2,
- .idProduct = 0x1008,
- .bInterfaceClass = 0xff,
- .bInterfaceSubClass = 0xff,
- .bInterfaceProtocol = 0xff,
- .driver_info = (unsigned long)&qmi_wwan_force_int4,
- },
- { /* ZTE (Vodafone) K3571-Z */
- .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = 0x19d2,
- .idProduct = 0x1010,
- .bInterfaceClass = 0xff,
- .bInterfaceSubClass = 0xff,
- .bInterfaceProtocol = 0xff,
- .driver_info = (unsigned long)&qmi_wwan_force_int4,
- },
- { /* ZTE (Vodafone) K3765-Z */
- .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = 0x19d2,
- .idProduct = 0x2002,
- .bInterfaceClass = 0xff,
- .bInterfaceSubClass = 0xff,
- .bInterfaceProtocol = 0xff,
- .driver_info = (unsigned long)&qmi_wwan_force_int4,
- },
- { /* ZTE (Vodafone) K4505-Z */
- .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = 0x19d2,
- .idProduct = 0x0104,
- .bInterfaceClass = 0xff,
- .bInterfaceSubClass = 0xff,
- .bInterfaceProtocol = 0xff,
- .driver_info = (unsigned long)&qmi_wwan_force_int4,
- },
- { /* ZTE MF60 */
- .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = 0x19d2,
- .idProduct = 0x1402,
- .bInterfaceClass = 0xff,
- .bInterfaceSubClass = 0xff,
- .bInterfaceProtocol = 0xff,
- .driver_info = (unsigned long)&qmi_wwan_force_int2,
- },
- { /* Sierra Wireless MC77xx in QMI mode */
- .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = 0x1199,
- .idProduct = 0x68a2,
- .bInterfaceClass = 0xff,
- .bInterfaceSubClass = 0xff,
- .bInterfaceProtocol = 0xff,
- .driver_info = (unsigned long)&qmi_wwan_sierra,
- },
- /* Gobi 1000 devices */
+ /* 3. Combined interface devices matching on interface number */
+ {QMI_FIXED_INTF(0x19d2, 0x0055, 1)}, /* ZTE (Vodafone) K3520-Z */
+ {QMI_FIXED_INTF(0x19d2, 0x0063, 4)}, /* ZTE (Vodafone) K3565-Z */
+ {QMI_FIXED_INTF(0x19d2, 0x0104, 4)}, /* ZTE (Vodafone) K4505-Z */
+ {QMI_FIXED_INTF(0x19d2, 0x0167, 4)}, /* ZTE MF820D */
+ {QMI_FIXED_INTF(0x19d2, 0x0326, 4)}, /* ZTE MF821D */
+ {QMI_FIXED_INTF(0x19d2, 0x1008, 4)}, /* ZTE (Vodafone) K3570-Z */
+ {QMI_FIXED_INTF(0x19d2, 0x1010, 4)}, /* ZTE (Vodafone) K3571-Z */
+ {QMI_FIXED_INTF(0x19d2, 0x1402, 2)}, /* ZTE MF60 */
+ {QMI_FIXED_INTF(0x19d2, 0x2002, 4)}, /* ZTE (Vodafone) K3765-Z */
+ {QMI_FIXED_INTF(0x1199, 0x68a2, 8)}, /* Sierra Wireless MC7710 in QMI mode */
+ {QMI_FIXED_INTF(0x1199, 0x68a2, 19)}, /* Sierra Wireless MC7710 in QMI mode */
+
+ /* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)}, /* Acer Gobi Modem Device */
{QMI_GOBI1K_DEVICE(0x03f0, 0x1f1d)}, /* HP un2400 Gobi Modem Device */
{QMI_GOBI1K_DEVICE(0x03f0, 0x371d)}, /* HP un2430 Mobile Broadband Module */
@@ -579,7 +420,7 @@ static const struct usb_device_id products[] = {
{QMI_GOBI1K_DEVICE(0x05c6, 0x9222)}, /* Generic Gobi Modem device */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9009)}, /* Generic Gobi Modem device */
- /* Gobi 2000 and 3000 devices */
+ /* 5. Gobi 2000 and 3000 devices */
{QMI_GOBI_DEVICE(0x413c, 0x8186)}, /* Dell Gobi 2000 Modem device (N0218, VU936) */
{QMI_GOBI_DEVICE(0x05c6, 0x920b)}, /* Generic Gobi 2000 Modem device */
{QMI_GOBI_DEVICE(0x05c6, 0x9225)}, /* Sony Gobi 2000 Modem device (N0279, VU730) */
--
1.7.10.4
^ permalink raw reply related
* [PATCH net 2/3] net: qmi_wwan: add Sierra Wireless devices
From: Bjørn Mork @ 2012-08-12 19:16 UTC (permalink / raw)
To: netdev; +Cc: linux-usb, Bjørn Mork
In-Reply-To: <1344798992-10176-1-git-send-email-bjorn@mork.no>
Add 6 new devices and one modified device, based on
information from laptop vendor Windows drivers.
Sony provides a driver with two new devices using
a Gobi 2k+ layout (1199:68a5 and 1199:68a9). The
Sony driver also adds a non-standard QMI/net
interface to the already supported 1199:9011
Gobi device. We do not know whether this is an
alternate interface number or an additional
interface which might be present, but that doesn't
really matter.
Lenovo provides a driver supporting 4 new devices:
- MC7770 (1199:901b) with standard Gobi 2k+ layout
- MC7700 (0f3d:68a2) with layout similar to MC7710
- MC7750 (114f:68a2) with layout similar to MC7710
- EM7700 (1199:901c) with layout similar to MC7710
Note regaring the three devices similar to MC7710:
The Windows drivers only support interface #8 on these
devices. The MC7710 can support QMI/net functions on
interface #19 and #20 as well, and this driver is
verified to work on interface #19 (a firmware bug is
suspected to prevent #20 from working).
We do not enable these additional interfaces until they
either show up in a Windows driver or are verified to
work in some other way. Therefore limiting the new
devices to interface #8 for now.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
drivers/net/usb/qmi_wwan.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index c6a5873..24524b2 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -401,8 +401,11 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x19d2, 0x1010, 4)}, /* ZTE (Vodafone) K3571-Z */
{QMI_FIXED_INTF(0x19d2, 0x1402, 2)}, /* ZTE MF60 */
{QMI_FIXED_INTF(0x19d2, 0x2002, 4)}, /* ZTE (Vodafone) K3765-Z */
+ {QMI_FIXED_INTF(0x0f3d, 0x68a2, 8)}, /* Sierra Wireless MC7700 */
+ {QMI_FIXED_INTF(0x114f, 0x68a2, 8)}, /* Sierra Wireless MC7750 */
{QMI_FIXED_INTF(0x1199, 0x68a2, 8)}, /* Sierra Wireless MC7710 in QMI mode */
{QMI_FIXED_INTF(0x1199, 0x68a2, 19)}, /* Sierra Wireless MC7710 in QMI mode */
+ {QMI_FIXED_INTF(0x1199, 0x901c, 8)}, /* Sierra Wireless EM7700 */
/* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)}, /* Acer Gobi Modem Device */
@@ -430,6 +433,8 @@ static const struct usb_device_id products[] = {
{QMI_GOBI_DEVICE(0x05c6, 0x9265)}, /* Asus Gobi 2000 Modem device (VR305) */
{QMI_GOBI_DEVICE(0x05c6, 0x9235)}, /* Top Global Gobi 2000 Modem device (VR306) */
{QMI_GOBI_DEVICE(0x05c6, 0x9275)}, /* iRex Technologies Gobi 2000 Modem device (VR307) */
+ {QMI_GOBI_DEVICE(0x1199, 0x68a5)}, /* Sierra Wireless Modem */
+ {QMI_GOBI_DEVICE(0x1199, 0x68a9)}, /* Sierra Wireless Modem */
{QMI_GOBI_DEVICE(0x1199, 0x9001)}, /* Sierra Wireless Gobi 2000 Modem device (VT773) */
{QMI_GOBI_DEVICE(0x1199, 0x9002)}, /* Sierra Wireless Gobi 2000 Modem device (VT773) */
{QMI_GOBI_DEVICE(0x1199, 0x9003)}, /* Sierra Wireless Gobi 2000 Modem device (VT773) */
@@ -441,11 +446,14 @@ static const struct usb_device_id products[] = {
{QMI_GOBI_DEVICE(0x1199, 0x9009)}, /* Sierra Wireless Gobi 2000 Modem device (VT773) */
{QMI_GOBI_DEVICE(0x1199, 0x900a)}, /* Sierra Wireless Gobi 2000 Modem device (VT773) */
{QMI_GOBI_DEVICE(0x1199, 0x9011)}, /* Sierra Wireless Gobi 2000 Modem device (MC8305) */
+ {QMI_FIXED_INTF(0x1199, 0x9011, 5)}, /* alternate interface number!? */
{QMI_GOBI_DEVICE(0x16d8, 0x8002)}, /* CMDTech Gobi 2000 Modem device (VU922) */
{QMI_GOBI_DEVICE(0x05c6, 0x9205)}, /* Gobi 2000 Modem device */
{QMI_GOBI_DEVICE(0x1199, 0x9013)}, /* Sierra Wireless Gobi 3000 Modem device (MC8355) */
{QMI_GOBI_DEVICE(0x1199, 0x9015)}, /* Sierra Wireless Gobi 3000 Modem device */
{QMI_GOBI_DEVICE(0x1199, 0x9019)}, /* Sierra Wireless Gobi 3000 Modem device */
+ {QMI_GOBI_DEVICE(0x1199, 0x901b)}, /* Sierra Wireless MC7770 */
+
{ } /* END */
};
MODULE_DEVICE_TABLE(usb, products);
--
1.7.10.4
^ permalink raw reply related
* [PATCH net 0/3] qmi_wwan: simplify device matching and add a few new devices
From: Bjørn Mork @ 2012-08-12 19:16 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, Bjørn Mork
The home cooked whitelisting code can be removed now that
the USB core supports interface number matching.
The second patch adds a few new devices.
The third patch improves device list readability by using
existing macros where possible.
I hope this can go in 3.6-rc2/3. The series is based on
the current net/master (commit 2359a476)
Bjørn Mork (3):
net: qmi_wwan: use fixed interface number matching
net: qmi_wwan: add Sierra Wireless devices
net: qmi_wwan: compress device_id list using macros
drivers/net/usb/qmi_wwan.c | 248 +++++++-------------------------------------
1 file changed, 40 insertions(+), 208 deletions(-)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Eric W. Biederman @ 2012-08-12 15:40 UTC (permalink / raw)
To: Or Gerlitz
Cc: Michael S. Tsirkin, Or Gerlitz, davem, roland, netdev, ali,
sean.hefty, Erez Shitrit, Doug Ledford
In-Reply-To: <CAJZOPZKtdvxTGvrxj+T896mEexb=yN9s1cCuqUmhhzCOvUPEnA@mail.gmail.com>
Or Gerlitz <or.gerlitz@gmail.com> writes:
> On Sun, Aug 5, 2012 at 9:50 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>
> [...]
>> So it seems that a sane solution would involve an extra level of
>> indirection, with guest addresses being translated to host IB addresses.
>> As long as you do this, maybe using an ethernet frame format makes sense.
> [...]
>
> Yep, that's among the points we're trying to make, the way you've put
> it makes it clearer.
>
>> - IGMP/MAC snooping in a driver is just too hairy.
>
> mmm, any rough idea/direction how to do that otherwise?
Let me give you a non-hack recomendation.
- Give up on being wire compatible with IPoIB.
- Define and implement ethernet over inifiniband aka EoIB.
With EoIB:
- The SM would map ethernet address to inifiniband hardware addresses.
- You discover which multicast addresses are of interest from the
IP layer above so no snooping is necessary.
- You could run queue pairs directly to hosts.
Shrug. It is trivial and it will work. It will probably run into the
same problems that have historically been a problem for using IPoIB
(lack of stateless offloads) but shrug that is mostly a NIC firmware
problem. The switches will have no trouble and interoperability will
be assured.
If you want to map ethernet over infiniband please map ethernet over
infiniband. Don't poorly NAT ethernet into infiniband.
Eric
^ permalink raw reply
* خصم 50% على اى حمله اعلانيه او اربح من موقعك من1الى 16$ لكل 1000 زائر
From: forex.gold.car @ 2012-08-12 14:55 UTC (permalink / raw)
To: netdev
السلام عليكم
وحياكم الله
أنا هشام محرم من فريق المبيعات بموقع
hivisits.com
لقد تشرفت بزياره وفحص موقعكم الكريم
ووجدت انه سيكون من المثمر والمفيد ان نتعاون سويا فى مجال التسويق الاعلانى
حيث يمكنكم الانضمام لنظامنا فى احد القسمين
قسم الناشرين
حيث يمكنكم فى هذا القسم نشر اعلاناتنا فى موقعكم الكريم
من خلال تركيب الكود الخاص بنا فى هيدر موقعكم ومشاهده الاعلانات المنبثقه تظهر فى موقع سيادتكم
يمكنكم الربح من خلال هذا القسم من 1-16 دولار امريكى لكل الف ظهور اعلانى من الفتحات المنسدله التى تظهر فى موقعكم
هذا ومن الجدير بالذكر ان الربح يزيد على حسب المنافسه على نوعيه الزائر ودولته فى نظامنا
يمكنكم التجربه الان http://www.hivisits.com/publishers
قسم المعلنين
يمكنكم التسويق او الترويج لموقعكم الكريم باقل الأسعار لدينا
بالنظام العالمى او نظام الاستهداف الفريد
مع وجود كوبونات خصم وعروض وتخفيضات يوميه
تستطيع ان تسوق وتعلن عن موقعك لدينا إبتداء من 1 دولار فقط
وتستطيع ان تحصل على مليون زائر ب 225 دولار فقط وهذا العرض هو هديتنا لسيادتكم لبدايه التعاون المثمر والبناء
يمكنكم تجربه الاعلان لدينا باستخدام هذا الكوبون الترويجى مع 33%خصم
use this Promocode: 50%offer
1Million visitors=$225 only
http://www.hivisits.com/advertisers
وسائل الدفع لارسال واستقبال التحويلات
جميع البنوك الاليكترونيه وطرق التحويل الدوليه والمحليه
http://www.hivisits.com/advertisers/manualpayment
بالاضافه الى البريد المصرى والتسليم اليدوى فى بعض الدول والمدن
كوبونات جوجل ادوردز فئه 100 دولار
كوبونات جوجل فنحن لدينا كميات كبيره وباسعار معقوله جدا
سعر الكوبون لاسعار الجمله
$1.5 فقط
وذلك لكوبونات ادوردز فئه 100دولار
نحن حريصون جدا على السماع منكم
ونتشرف بتواصل سيادتكم معنا عبر الوسائل التاليه
http://www.hivisits.com/contactus
وتفضلوا بقبول فائق التحيه والاحترام
دمتم بخير
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Or Gerlitz @ 2012-08-12 14:13 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Eric W. Biederman, davem, roland, netdev, ali, sean.hefty,
Erez Shitrit, Doug Ledford
In-Reply-To: <20120812135544.GB6003@redhat.com>
On 12/08/2012 16:55, Michael S. Tsirkin wrote:
> I didn't realize you do ARP snooping. Why? I know you mangle outgoing
> ARP packets,
Maybe I wasn't accurate/clear, we do mangle outgoing/incoming ARP
packets, from/to Ethernet ARPs
to/from IPoIB ARPs.
> this will go away if you maintain a mapping in SM accessible to all
> guests.
guests don't interact with IB, I assume you referred to dom0 code, eIPoIB or
another driver in the host. But what mapping exactly? and remember that
this code (VM through eipoib) can talk to any IPoIB element on the
fabric, native,
virtualized, HW/SW gateways, etc etc.
Or.
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Michael S. Tsirkin @ 2012-08-12 14:05 UTC (permalink / raw)
To: Or Gerlitz
Cc: Eric W. Biederman, Ali Ayoub, David Miller, ogerlitz, roland,
netdev, sean.hefty, erezsh, dledford
In-Reply-To: <CAJZOPZKVjxaf1Sqchm4X4nKhYLR5yxnMiTjmvx1n4OELu=jhbg@mail.gmail.com>
On Thu, Aug 09, 2012 at 07:06:46AM +0300, Or Gerlitz wrote:
> Eric W. Biederman <ebiederm@xmission.com> wrote:
> > Or Gerlitz <or.gerlitz@gmail.com> writes:
>
> >> To put things in place, DHCPv4 is supported with eIPoIB, the DHCP
> >> UDP/IP payload isn't touched, only need to set the BOOTP broadcast
> >> flag in the dhcp server config file.
>
> > Wrong. DHCPv4 is broken over eIPoIB. Coming from ethernet
> > htype == 1 not 32 as required by RFC4390
> > hlen == 6 not 0 as required by RFC4390
> > The chaddr field is has 6 bytes of the ethernet mac address not the
> > required 16 bytes of 0. The client-identifier field is optional over ethernet.
> > An ethernet DHCPv4 client simply does not generate a dhcp packet that
> > conforms to RFC4390.
> >
> > Therefore DHCPv4 over eIPoIB is broken, and a dhcp server or relay
> > may reasonably look at the DHCP packet and drop it because it is garbage.
> >
> > You might find a forgiving dhcp server that doesn't drop insane packets
> > on the floor and tries to make things work.
>
> Under the eIPoIB design, the VM DHCP interaction follows
> Ethernet DHCP, and not the IPoIB DHCP (RFC 4390).
>
> The DHCP server has no reason to drop such packets.
>
> DHCP is a L7 (L5 to be precise) construct, I don't see
> why that the fact IPoIB DHCP RFC exists, means/mandates
> the DHCP server to care on the link layer type.
>
> Or.
For example DHCP server could be configured with
HW address/IP address table.
--
MST
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Michael S. Tsirkin @ 2012-08-12 13:55 UTC (permalink / raw)
To: Or Gerlitz
Cc: Or Gerlitz, Eric W. Biederman, davem, roland, netdev, ali,
sean.hefty, Erez Shitrit, Doug Ledford
In-Reply-To: <5027AC88.2020509@mellanox.com>
On Sun, Aug 12, 2012 at 04:15:52PM +0300, Or Gerlitz wrote:
> On 12/08/2012 13:22, Michael S. Tsirkin wrote:
> >>>>>- IGMP/MAC snooping in a driver is just too hairy.
> >>
> >>>mmm, any rough idea/direction how to do that otherwise?
> >Sure, even two ways, ideally you'd do both:)
> >A. fix macvtap
> >1. Use netdev_for_each_mc_addr etc to get multicast addresses
> >2. teach macvtap to fill that in (it currently floods multicasts
> > for guest to guest communication so we ned to fix it anyway)
> >
> >B. fix bridge
> > teach bridge to work for VMs without using promisc mode
>
> I wasn't sure to fully follow... need some more bits of info, the
> macvtap fix
> relates only to IGMP snooping, correct? as for the bridge fix, does
> this somehow
> relates to ARP snooping we do in the driver? how?
>
> Or.
I didn't realize you do ARP snooping. Why?
I know you mangle outgoing ARP packets, this will go
away if you maintain a mapping in SM accessible to all guests.
--
MST
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Michael S. Tsirkin @ 2012-08-12 13:41 UTC (permalink / raw)
To: Or Gerlitz
Cc: Eric W. Biederman, davem, roland, netdev, ali, sean.hefty,
Erez Shitrit, Doug Ledford
In-Reply-To: <5027AB0F.7010102@mellanox.com>
On Sun, Aug 12, 2012 at 04:09:35PM +0300, Or Gerlitz wrote:
> On 12/08/2012 13:22, Michael S. Tsirkin wrote:
> >On Wed, Aug 08, 2012 at 08:23:15AM +0300, Or Gerlitz wrote:
> >>>On Sun, Aug 5, 2012 at 9:50 PM, Michael S. Tsirkin<mst@redhat.com> wrote:
> >>>
> >>>[...]
> >>>> >So it seems that a sane solution would involve an extra level of
> >>>> >indirection, with guest addresses being translated to host IB addresses.
> >>>> >As long as you do this, maybe using an ethernet frame format makes sense.
> >>>[...]
> >>>
> >>>Yep, that's among the points we're trying to make, the way you've put
> >>>it makes it clearer.
> >>>
> >>>> >So far the things that make sense. Here are some that don't, to me:
> >>>
> >>>> >- Is a pdf presentation all you have in terms of documentation?
> >>>> > We are talking communication protocols here - I would expect a
> >>>> > proper spec, and some effort to standardize, otherwise where's the
> >>>> > guarantee it won't change in an incompatible way?
> >>>
> >>>To be precise, the solution uses 100% IPoIB wire-protocol, so we don't
> >>>see a need
> >>>for any spec change / standardization effort.
> >Yes, I am guessing this is the real reason you pack LID/QPN
> >in the MAC - to make it all local. But it's a hack really,
> >and if you start storing it all in the SM you will need
> >to document the format so others can inter-operate.
>
> I'd like to review the way we generate these MAC addresses, maybe it
> can be done differently.
>
>
> >
> >
> >>>This might go to the 1stpoint you've
> >>>brought... improve the documentation, will do that. The pdf you looked
> >>>at was presentedin a conference.
> >>
> >>>> > Other things that I would expect to be addressed in such a spec is
> >>>> > interaction with other IPoIB features, such as connected
> >>>> > mode, checksum offloading etc, and IB features such as multipath etc.
> >>>
> >>>For the eipoib interface, it doesn't really matters if the underlyind
> >>>ipoib clones used by it (we call them VIFs) use connected or datagram
> >>>mode, what does matter is the MTU and offload features supported by
> >>>these VIFs, for which the eipoib interface will have the min among all
> >>>these VIFs. Since for a given eipoib nic, all its VIFs must originated
> >>>from the same IPoIB PIF (e.g ib0) its easy admin job to make sure they
> >>>all have the same mtu / features which are needed for that eipoib nic,
> >>>e.g by using the same mode (connected/datagram for all of them), hope
> >>>this is clear.
> >>>
> >Just pointing out all this needs to be documented.
>
> OK, will do
>
> >
> >
> >>>> >- The way you encode LID/QPN in the MAC seems questionable. IIRC there's
> >>>> > more to IB addressing than just the LID. Since everyone on the subnet
> >>>> > need access to this translation, I think it makes sense to store it in
> >>>> > the SM. I think this would also obviate some IPv4 specific hacks in kernel.
> >>>
> >>>The idead beyond the encoding was uniqueness, LID/QPN is unique per IB
> >>>HCA end-node.
> >But then it breaks with VM migration, IB failover, softmac setting in guest, probably more?
>
> With the current design/code the remote mac of a VM changes, when
> that VM migrates or IB
> LIDs are changed.
Which is exactly the problem with IB and VM migration.
> As for softmac setting in the guest, we don't
> send the guest MAC on the wire
> anyway, since the Ethernet header is removed.
>
> Or.
Yes but you generate remote addresses automatically so admin can not
change the local address without risking conflicts.
--
MST
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Or Gerlitz @ 2012-08-12 13:19 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Eric W. Biederman, davem, roland, netdev, ali, sean.hefty,
Erez Shitrit, Doug Ledford
In-Reply-To: <20120812105421.GI1421@redhat.com>
On 12/08/2012 13:54, Michael S. Tsirkin wrote:
> On Wed, Aug 08, 2012 at 08:23:15AM +0300, Or Gerlitz wrote:
>>> So far the things that make sense. Here are some that don't, to me:
>>> - Is a pdf presentation all you have in terms of documentation?
>>> We are talking communication protocols here - I would expect a
>>> proper spec, and some effort to standardize, otherwise where's the
>>> guarantee it won't change in an incompatible way?
>> To be precise, the solution uses 100% IPoIB wire-protocol, so we don't
>> see a need for any spec change / standardization effort.
> Thinking about it some more, the solution is not really 100% local:
> - ARP packets used at migration are visible on the network
The ARP packets on the wire are IPoIB ARP packets -- indeed, when the
guest moves, the IPoIB
link layer address which was associated with the VIF that used to serve
this guest on the host
we migrated from, changes to be of a VIF on the host that we migrated to.
> - QPN/LID in MAC are guest visible, and could be exported on the network
>
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Or Gerlitz @ 2012-08-12 13:15 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Or Gerlitz, Eric W. Biederman, davem, roland, netdev, ali,
sean.hefty, Erez Shitrit, Doug Ledford
In-Reply-To: <20120812102240.GG1421@redhat.com>
On 12/08/2012 13:22, Michael S. Tsirkin wrote:
>>> >>- IGMP/MAC snooping in a driver is just too hairy.
>>
>> >mmm, any rough idea/direction how to do that otherwise?
> Sure, even two ways, ideally you'd do both:)
> A. fix macvtap
> 1. Use netdev_for_each_mc_addr etc to get multicast addresses
> 2. teach macvtap to fill that in (it currently floods multicasts
> for guest to guest communication so we ned to fix it anyway)
>
> B. fix bridge
> teach bridge to work for VMs without using promisc mode
I wasn't sure to fully follow... need some more bits of info, the
macvtap fix
relates only to IGMP snooping, correct? as for the bridge fix, does this
somehow
relates to ARP snooping we do in the driver? how?
Or.
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Or Gerlitz @ 2012-08-12 13:09 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Eric W. Biederman, davem, roland, netdev, ali, sean.hefty,
Erez Shitrit, Doug Ledford
In-Reply-To: <20120812102240.GG1421@redhat.com>
On 12/08/2012 13:22, Michael S. Tsirkin wrote:
> On Wed, Aug 08, 2012 at 08:23:15AM +0300, Or Gerlitz wrote:
>> >On Sun, Aug 5, 2012 at 9:50 PM, Michael S. Tsirkin<mst@redhat.com> wrote:
>> >
>> >[...]
>>> > >So it seems that a sane solution would involve an extra level of
>>> > >indirection, with guest addresses being translated to host IB addresses.
>>> > >As long as you do this, maybe using an ethernet frame format makes sense.
>> >[...]
>> >
>> >Yep, that's among the points we're trying to make, the way you've put
>> >it makes it clearer.
>> >
>>> > >So far the things that make sense. Here are some that don't, to me:
>> >
>>> > >- Is a pdf presentation all you have in terms of documentation?
>>> > > We are talking communication protocols here - I would expect a
>>> > > proper spec, and some effort to standardize, otherwise where's the
>>> > > guarantee it won't change in an incompatible way?
>> >
>> >To be precise, the solution uses 100% IPoIB wire-protocol, so we don't
>> >see a need
>> >for any spec change / standardization effort.
> Yes, I am guessing this is the real reason you pack LID/QPN
> in the MAC - to make it all local. But it's a hack really,
> and if you start storing it all in the SM you will need
> to document the format so others can inter-operate.
I'd like to review the way we generate these MAC addresses, maybe it
can be done differently.
>
>
>> >This might go to the 1stpoint you've
>> >brought... improve the documentation, will do that. The pdf you looked
>> >at was presentedin a conference.
>>
>>> > > Other things that I would expect to be addressed in such a spec is
>>> > > interaction with other IPoIB features, such as connected
>>> > > mode, checksum offloading etc, and IB features such as multipath etc.
>> >
>> >For the eipoib interface, it doesn't really matters if the underlyind
>> >ipoib clones used by it (we call them VIFs) use connected or datagram
>> >mode, what does matter is the MTU and offload features supported by
>> >these VIFs, for which the eipoib interface will have the min among all
>> >these VIFs. Since for a given eipoib nic, all its VIFs must originated
>> >from the same IPoIB PIF (e.g ib0) its easy admin job to make sure they
>> >all have the same mtu / features which are needed for that eipoib nic,
>> >e.g by using the same mode (connected/datagram for all of them), hope
>> >this is clear.
>> >
> Just pointing out all this needs to be documented.
OK, will do
>
>
>>> > >- The way you encode LID/QPN in the MAC seems questionable. IIRC there's
>>> > > more to IB addressing than just the LID. Since everyone on the subnet
>>> > > need access to this translation, I think it makes sense to store it in
>>> > > the SM. I think this would also obviate some IPv4 specific hacks in kernel.
>> >
>> >The idead beyond the encoding was uniqueness, LID/QPN is unique per IB
>> >HCA end-node.
> But then it breaks with VM migration, IB failover, softmac setting in guest, probably more?
With the current design/code the remote mac of a VM changes, when that
VM migrates or IB
LIDs are changed. As for softmac setting in the guest, we don't send
the guest MAC on the wire
anyway, since the Ethernet header is removed.
Or.
^ permalink raw reply
* Re: [PATCH V3] CS89x0 : Use ioread16/iowrite16 on all platforms
From: Domenico Andreoli @ 2012-08-12 11:24 UTC (permalink / raw)
To: David Miller
Cc: jaccon.bastiaansen, arnd, netdev, s.hauer, romieu, joe, gfm,
festevam, linux-arm-kernel
In-Reply-To: <20120517.190346.175685939436302276.davem@davemloft.net>
On Thu, May 17, 2012 at 07:03:46PM -0400, David Miller wrote:
> From: Jaccon Bastiaansen <jaccon.bastiaansen@gmail.com>
> Date: Thu, 17 May 2012 19:11:42 +0200
>
> > The use of the inw/outw functions by the cs89x0 platform driver
> > results in NULL pointer references on ARM platforms and
> > platforms that do not provide ISA-style programmed I/O accessors.
> >
> > Using inw/outw also accesses the wrong address space on platforms
> > that have a PCI I/O space that is not identity-mapped into the
> > physical address space.
> >
> > Signed-off-by: Jaccon Bastiaansen <jaccon.bastiaansen@gmail.com>
>
> I could nit-pick more on this patch, but it's such a significant
> improvement I'm just going to apply this V3 as-is to net-next.
Is this going into v3.6 or v3.7?
cheers,
Domenico
^ permalink raw reply
* Matter that needs your attention
From: Ooi, teek @ 2012-08-12 10:05 UTC (permalink / raw)
To: netdev
Good day,
This is a personal email directed to you for your consideration alone, I
request that it remain and be treated as such only. Please bear with me for
now and do not ask my name. I am a banker here in Malaysia
I have an interesting business proposal for you that will be of immense
benefit to both of us. Although this may be hard for you to believe, we
stand to gain 7.2 million USD between us in a matter of days. Please grant
me the benefit of doubt and hear me out. I need you to signify your interest
by replying to this email..
Most importantly, I will need you to promise to keep whatever you learn from
me between us even if you decide not to go along with me. I will make more
details available to you on receipt of a positive response from you.
Warm regards from
Malaysia
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Michael S. Tsirkin @ 2012-08-12 10:54 UTC (permalink / raw)
To: Or Gerlitz
Cc: Eric W. Biederman, Or Gerlitz, davem, roland, netdev, ali,
sean.hefty, Erez Shitrit, Doug Ledford
In-Reply-To: <CAJZOPZKtdvxTGvrxj+T896mEexb=yN9s1cCuqUmhhzCOvUPEnA@mail.gmail.com>
On Wed, Aug 08, 2012 at 08:23:15AM +0300, Or Gerlitz wrote:
> > So far the things that make sense. Here are some that don't, to me:
>
> > - Is a pdf presentation all you have in terms of documentation?
> > We are talking communication protocols here - I would expect a
> > proper spec, and some effort to standardize, otherwise where's the
> > guarantee it won't change in an incompatible way?
>
> To be precise, the solution uses 100% IPoIB wire-protocol, so we don't
> see a need
> for any spec change / standardization effort.
Thinking about it some more, the solution is not really 100% local:
- ARP packets used at migration are visible on the network
- QPN/LID in MAC are guest visible, and could be exported on the network
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Michael S. Tsirkin @ 2012-08-12 10:36 UTC (permalink / raw)
To: Or Gerlitz
Cc: Eric W. Biederman, Ali Ayoub, David Miller, ogerlitz, roland,
netdev, sean.hefty, erezsh, dledford
In-Reply-To: <CAJZOPZ+JKZAxF-SaWxCd_8pLqhrLXrPyQHEo0n-gNzuvMOA02w@mail.gmail.com>
On Thu, Aug 09, 2012 at 07:34:23AM +0300, Or Gerlitz wrote:
> > Infiniband is standard enough you could quite easily implement virtual
> > infiniband bridging as an alternative to ethernet bridging.
>
> Not really, as Michael indicated in his response over this thread
> http://marc.info/?l=linux-netdev&m=134419288218373&w=2
> IPoIB link layer addresses use IB HW constructs for which soft
> hardware address setting isn't supported, and this interferes
> with live migration.
>
> Or.
But I'd just like to point out your code does not support softmac
either.
--
MST
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Michael S. Tsirkin @ 2012-08-12 10:22 UTC (permalink / raw)
To: Or Gerlitz
Cc: Eric W. Biederman, Or Gerlitz, davem, roland, netdev, ali,
sean.hefty, Erez Shitrit, Doug Ledford
In-Reply-To: <CAJZOPZKtdvxTGvrxj+T896mEexb=yN9s1cCuqUmhhzCOvUPEnA@mail.gmail.com>
On Wed, Aug 08, 2012 at 08:23:15AM +0300, Or Gerlitz wrote:
> On Sun, Aug 5, 2012 at 9:50 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>
> [...]
> > So it seems that a sane solution would involve an extra level of
> > indirection, with guest addresses being translated to host IB addresses.
> > As long as you do this, maybe using an ethernet frame format makes sense.
> [...]
>
> Yep, that's among the points we're trying to make, the way you've put
> it makes it clearer.
>
> > So far the things that make sense. Here are some that don't, to me:
>
> > - Is a pdf presentation all you have in terms of documentation?
> > We are talking communication protocols here - I would expect a
> > proper spec, and some effort to standardize, otherwise where's the
> > guarantee it won't change in an incompatible way?
>
> To be precise, the solution uses 100% IPoIB wire-protocol, so we don't
> see a need
> for any spec change / standardization effort.
Yes, I am guessing this is the real reason you pack LID/QPN
in the MAC - to make it all local. But it's a hack really,
and if you start storing it all in the SM you will need
to document the format so others can inter-operate.
> This might go to the 1st
> point you've
> brought... improve the documentation, will do that. The pdf you looked
> at was presented
> in a conference.
>
> > Other things that I would expect to be addressed in such a spec is
> > interaction with other IPoIB features, such as connected
> > mode, checksum offloading etc, and IB features such as multipath etc.
>
> For the eipoib interface, it doesn't really matters if the underlyind
> ipoib clones used by it (we call them VIFs) use connected or datagram
> mode, what does matter is the MTU and offload features supported by
> these VIFs, for which the eipoib interface will have the min among all
> these VIFs. Since for a given eipoib nic, all its VIFs must originated
> from the same IPoIB PIF (e.g ib0) its easy admin job to make sure they
> all have the same mtu / features which are needed for that eipoib nic,
> e.g by using the same mode (connected/datagram for all of them), hope
> this is clear.
>
Just pointing out all this needs to be documented.
> > - The way you encode LID/QPN in the MAC seems questionable. IIRC there's
> > more to IB addressing than just the LID. Since everyone on the subnet
> > need access to this translation, I think it makes sense to store it in
> > the SM. I think this would also obviate some IPv4 specific hacks in kernel.
>
> The idead beyond the encoding was uniqueness, LID/QPN is unique per IB
> HCA end-node.
But then it breaks with VM migration, IB failover, softmac setting in
guest, probably more?
> I wasn't sure to understand the comment re the IPv4 hacks.
This refers to the ARP hack that you use to fix
VM migration.
> > - IGMP/MAC snooping in a driver is just too hairy.
>
> mmm, any rough idea/direction how to do that otherwise?
Sure, even two ways, ideally you'd do both :)
A. fix macvtap
1. Use netdev_for_each_mc_addr etc to get multicast addresses
2. teach macvtap to fill that in (it currently floods multicasts
for guest to guest communication so we ned to fix it anyway)
B. fix bridge
teach bridge to work for VMs without using promisc mode
> > As you point out, bridge currently needs the uplink in promisc mode.
> > I don't think a driver should work around that limitation.
> > For some setups, it might be interesting to remove the
> > promisc mode requirement, failing that,
> > I think you could use macvtap passthrough.
>
> That's in the plans, the current code doesn't assume that the eipoib
> has bridge on top, for VM networking it works with bridge + tap,
> bridge + macvtap, but it would easily work with passthrough when we
> allow to create multiple eipoib interfaces on the same ipoib PIF (e.g
> today for the ib0 PIF we create eipoib eth0, and then two VIFs ib0.1
> and ib0.2 that are enslaved by eth0, but next we will create eth1 and
> eth2 which will use ib0.1 and ib0.2
> respectively.
The whole promisc mode emulation is there for the bridge, no?
Since you don't support promisc, ideally we'd check a hardware
capability and fail gracefully, though naturally this is not top
priority.
> > - Currently migration works without host kernel help, would be
> > preferable to keep it that way.
>
> OK
^ permalink raw reply
* Re: [Question]About KVM network zero-copy feature!
From: Michael S. Tsirkin @ 2012-08-12 9:37 UTC (permalink / raw)
To: Robert Vineyard
Cc: xiaohui.xin, kvm, netdev, Peter Huang(Peng), virtualization, avi,
Stephen Hemminger
In-Reply-To: <5026FC04.6080108@tuffmail.com>
On Sat, Aug 11, 2012 at 08:42:44PM -0400, Robert Vineyard wrote:
> (adding Xin Xiaohui to the conversation for comment)
>
> According to the NetworkingTodo page on the KVM wiki, zero-copy RX
> for macvtap is in fact on the roadmap, assigned to Xin:
>
> http://www.linux-kvm.org/page/NetworkingTodo
AFAIK Xin left Intel and is not working on it.
Contributions are welcome.
> The Release Notes for RHEL 6.2 (originally published on 12/06/2011)
> also specifically mention macvtap/vhost zero-copy capabilities as
> being included as a Technology Preview:
>
> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/6.2_Release_Notes/virtualization.html
>
> Since I've been unable to find much information on the current
> status of this development, can anyone confirm if this functionality
> is still in the works? If so, is there any planned ETA?
>
> Thanks,
> Robert Vineyard
I think this means TX.
--
MST
^ 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