* [PATCHv2 14/14] vhost: fix 64 bit features
From: Michael S. Tsirkin @ 2011-05-19 23:12 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Krishna Kumar, Carsten Otte, lguest-uLR06cmDAlY/bJ5BZ2RsiQ,
Shirley Ma, kvm-u79uwXL29TY76Z2rM5mHXA,
linux-s390-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
habanero-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8, Heiko Carstens,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
steved-r/Jw6+rmf7HQT0dZR+AlfA, Christian Borntraeger,
Tom Lendacky, Martin Schwidefsky, linux390-tA70FqPdS9bQT0dZR+AlfA
In-Reply-To: <cover.1305846412.git.mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Update vhost_has_feature to make it work correctly for bit > 32.
Signed-off-by: Michael S. Tsirkin <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
drivers/vhost/vhost.h | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 8e03379..64889d2 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -123,7 +123,7 @@ struct vhost_dev {
struct vhost_memory __rcu *memory;
struct mm_struct *mm;
struct mutex mutex;
- unsigned acked_features;
+ u64 acked_features;
struct vhost_virtqueue *vqs;
int nvqs;
struct file *log_file;
@@ -176,14 +176,14 @@ enum {
(1ULL << VIRTIO_NET_F_MRG_RXBUF),
};
-static inline int vhost_has_feature(struct vhost_dev *dev, int bit)
+static inline bool vhost_has_feature(struct vhost_dev *dev, int bit)
{
- unsigned acked_features;
+ u64 acked_features;
/* TODO: check that we are running from vhost_worker or dev mutex is
* held? */
acked_features = rcu_dereference_index_check(dev->acked_features, 1);
- return acked_features & (1 << bit);
+ return acked_features & (1ull << bit);
}
#endif
--
1.7.5.53.gc233e
^ permalink raw reply related
* Re: [PATCH net-next 10/13] tg3: Consolidate all netdev feature assignments
From: Mahesh Bandewar @ 2011-05-19 23:15 UTC (permalink / raw)
To: Matt Carlson; +Cc: David Miller, linux-netdev
In-Reply-To: <1305843176-32358-11-git-send-email-mcarlson@broadcom.com>
On Thu, May 19, 2011 at 3:12 PM, Matt Carlson <mcarlson@broadcom.com> wrote:
> This patch consolidates all the netdev feature bit assignments to one
> location.
>
> Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> Reviewed-by: Michael Chan <mchan@broadcom.com>
> ---
> drivers/net/tg3.c | 51 ++++++++++++++++++++++++---------------------------
> 1 files changed, 24 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
> index 09fe067..5bf2ce1 100644
> --- a/drivers/net/tg3.c
> +++ b/drivers/net/tg3.c
> @@ -13602,19 +13602,6 @@ static int __devinit tg3_get_invariants(struct tg3 *tp)
> tg3_flag(tp, 5750_PLUS))
> tg3_flag_set(tp, 5705_PLUS);
>
> - /* 5700 B0 chips do not support checksumming correctly due
> - * to hardware bugs.
> - */
> - if (tp->pci_chip_rev_id != CHIPREV_ID_5700_B0) {
> - u32 features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_RXCSUM;
> -
> - if (tg3_flag(tp, 5755_PLUS))
> - features |= NETIF_F_IPV6_CSUM;
> - tp->dev->features |= features;
> - tp->dev->hw_features |= features;
> - tp->dev->vlan_features |= features;
> - }
> -
> /* Determine TSO capabilities */
> if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5719)
> ; /* Do nothing. HW bug. */
> @@ -14922,7 +14909,7 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
> u32 sndmbx, rcvmbx, intmbx;
> char str[40];
> u64 dma_mask, persist_dma_mask;
> - u32 hw_features = 0;
> + u32 features = 0;
>
> printk_once(KERN_INFO "%s\n", version);
>
> @@ -14958,8 +14945,6 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
>
> SET_NETDEV_DEV(dev, &pdev->dev);
>
> - dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
> -
> tp = netdev_priv(dev);
> tp->pdev = pdev;
> tp->dev = dev;
> @@ -15039,7 +15024,7 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
> if (dma_mask > DMA_BIT_MASK(32)) {
> err = pci_set_dma_mask(pdev, dma_mask);
> if (!err) {
> - dev->features |= NETIF_F_HIGHDMA;
> + features |= NETIF_F_HIGHDMA;
> err = pci_set_consistent_dma_mask(pdev,
> persist_dma_mask);
> if (err < 0) {
> @@ -15060,6 +15045,18 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
>
> tg3_init_bufmgr_config(tp);
>
> + features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
> +
> + /* 5700 B0 chips do not support checksumming correctly due
> + * to hardware bugs.
> + */
> + if (tp->pci_chip_rev_id != CHIPREV_ID_5700_B0) {
> + features |= NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_RXCSUM;
> +
> + if (tg3_flag(tp, 5755_PLUS))
> + features |= NETIF_F_IPV6_CSUM;
> + }
> +
> /* TSO is on by default on chips that support hardware TSO.
> * Firmware TSO on older chips gives lower performance, so it
> * is off by default, but can be enabled using ethtool.
> @@ -15067,24 +15064,20 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
> if ((tg3_flag(tp, HW_TSO_1) ||
> tg3_flag(tp, HW_TSO_2) ||
> tg3_flag(tp, HW_TSO_3)) &&
> - (dev->features & NETIF_F_IP_CSUM))
> - hw_features |= NETIF_F_TSO;
> + (features & NETIF_F_IP_CSUM))
> + features |= NETIF_F_TSO;
> if (tg3_flag(tp, HW_TSO_2) || tg3_flag(tp, HW_TSO_3)) {
> - if (dev->features & NETIF_F_IPV6_CSUM)
> - hw_features |= NETIF_F_TSO6;
> + if (features & NETIF_F_IPV6_CSUM)
> + features |= NETIF_F_TSO6;
> if (tg3_flag(tp, HW_TSO_3) ||
> GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5761 ||
> (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5784 &&
> GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5784_AX) ||
> GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5785 ||
> GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_57780)
> - hw_features |= NETIF_F_TSO_ECN;
> + features |= NETIF_F_TSO_ECN;
> }
>
> - dev->hw_features |= hw_features;
> - dev->features |= hw_features;
> - dev->vlan_features |= hw_features;
> -
> /*
> * Add loopback capability only for a subset of devices that support
> * MAC-LOOPBACK. Eventually this need to be enhanced to allow INT-PHY
> @@ -15093,7 +15086,11 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
> if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5780 &&
> !tg3_flag(tp, CPMU_PRESENT))
> /* Add the loopback capability */
> - dev->hw_features |= NETIF_F_LOOPBACK;
> + features |= NETIF_F_LOOPBACK;
> +
> + dev->features |= features;
This will set the loopback by default for the described sub-set.
> + dev->hw_features |= features;
Yes, you just want to add that here only.
> + dev->vlan_features |= features;
>
> if (tp->pci_chip_rev_id == CHIPREV_ID_5705_A1 &&
> !tg3_flag(tp, TSO_CAPABLE) &&
> --
> 1.7.3.4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: TCP funny-ness when over-driving a 1Gbps link.
From: Stephen Hemminger @ 2011-05-19 23:18 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4DD59DF2.2070707@candelatech.com>
On Thu, 19 May 2011 15:47:14 -0700
Ben Greear <greearb@candelatech.com> wrote:
> I noticed something that struck me as a bit weird today,
> but perhaps it's normal.
>
> I was using our application to create 3 TCP streams from one port to
> another (1Gbps, igb driver), running through a network emulator.
> Traffic is flowing bi-directional in each connection.
>
> I am doing 24k byte writes per system call. I tried 100ms, 10ms, and 1ms
> latency (one-way) in the emulator, but behaviour is similar in each case.
> The rest of this info was gathered with 1ms delay in the emulator.
>
> If I ask all 3 connections to run 1Gbps, netstat shows 30+GB in the
> sending queues and 1+ second latency (user-space to user-space). Aggregate
> throughput is around 700Mbps in each direction.
>
> But, if I ask each of the connections to run at 300Mbps, latency averages
> 2ms and each connection runs right at 300Mbps (950Mbps or so on the wire).
>
> It seems that when you over-drive the link, things back up and perform
> quite badly over-all.
>
> This is a core-i7 3.2Ghz with 12GB RAM, Fedora 14, 2.6.38.6 kernel
> (with some hacks), 64-bit OS and user-space app. Quick testing on 2.6.36.3
> showed similar results, so I don't think it's a regression.
>
> I am curious if others see similar results?
>
> Thanks,
> Ben
>
If you overdrive, TCP expects your network emulator to have
a some but limited queueing (like a real router).
--
^ permalink raw reply
* Re: [PATCHv2 00/14] virtio and vhost-net performance enhancements
From: David Miller @ 2011-05-19 23:20 UTC (permalink / raw)
To: mst
Cc: linux-kernel, rusty, cotte, borntraeger, linux390, schwidefsky,
heiko.carstens, xma, lguest, virtualization, netdev, linux-s390,
kvm, krkumar2, tahm, steved, habanero
In-Reply-To: <cover.1305846412.git.mst@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Fri, 20 May 2011 02:10:07 +0300
> Rusty, I think it will be easier to merge vhost and virtio bits in one
> go. Can it all go in through your tree (Dave in the past acked
> sending a very similar patch through you so should not be a problem)?
And in case you want an explicit ack for the net bits:
Acked-by: David S. Miller <davem@davemloft.net>
:-)
^ permalink raw reply
* Re: TCP funny-ness when over-driving a 1Gbps link.
From: Ben Greear @ 2011-05-19 23:20 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20110519161827.2ba4b40e@nehalam>
On 05/19/2011 04:18 PM, Stephen Hemminger wrote:
> On Thu, 19 May 2011 15:47:14 -0700
> Ben Greear<greearb@candelatech.com> wrote:
>
>> I noticed something that struck me as a bit weird today,
>> but perhaps it's normal.
>>
>> I was using our application to create 3 TCP streams from one port to
>> another (1Gbps, igb driver), running through a network emulator.
>> Traffic is flowing bi-directional in each connection.
>>
>> I am doing 24k byte writes per system call. I tried 100ms, 10ms, and 1ms
>> latency (one-way) in the emulator, but behaviour is similar in each case.
>> The rest of this info was gathered with 1ms delay in the emulator.
>>
>> If I ask all 3 connections to run 1Gbps, netstat shows 30+GB in the
>> sending queues and 1+ second latency (user-space to user-space). Aggregate
>> throughput is around 700Mbps in each direction.
>>
>> But, if I ask each of the connections to run at 300Mbps, latency averages
>> 2ms and each connection runs right at 300Mbps (950Mbps or so on the wire).
>>
>> It seems that when you over-drive the link, things back up and perform
>> quite badly over-all.
>>
>> This is a core-i7 3.2Ghz with 12GB RAM, Fedora 14, 2.6.38.6 kernel
>> (with some hacks), 64-bit OS and user-space app. Quick testing on 2.6.36.3
>> showed similar results, so I don't think it's a regression.
>>
>> I am curious if others see similar results?
>>
>> Thanks,
>> Ben
>>
>
> If you overdrive, TCP expects your network emulator to have
> a some but limited queueing (like a real router).
The emulator is fine, it's not being over-driven (and has limited queueing if it was
being over-driven). The queues that are backing up are in the tcp sockets on the
sending machine.
But, just to make sure, I'll re-run the test with a looped back cable...
Ben
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] networking: NET_CLS_ROUTE4 depends on INET
From: Randy Dunlap @ 2011-05-19 23:22 UTC (permalink / raw)
To: netdev; +Cc: davem, Jamal Hadi Salim
From: Randy Dunlap <randy.dunlap@oracle.com>
IP_ROUTE_CLASSID depends on INET and NET_CLS_ROUTE4 selects
IP_ROUTE_CLASSID, but when INET is not enabled, this kconfig warning
is produced, so fix it by making NET_CLS_ROUTE4 depend on INET.
warning: (NET_CLS_ROUTE4) selects IP_ROUTE_CLASSID which has unmet direct dependencies (NET && INET)
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
net/sched/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- lnx-2639.orig/net/sched/Kconfig
+++ lnx-2639/net/sched/Kconfig
@@ -277,6 +277,7 @@ config NET_CLS_TCINDEX
config NET_CLS_ROUTE4
tristate "Routing decision (ROUTE)"
+ depends on INET
select IP_ROUTE_CLASSID
select NET_CLS
---help---
^ permalink raw reply
* Re: [PATCH] networking: NET_CLS_ROUTE4 depends on INET
From: David Miller @ 2011-05-19 23:23 UTC (permalink / raw)
To: randy.dunlap; +Cc: netdev, hadi
In-Reply-To: <20110519162218.b0344392.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Thu, 19 May 2011 16:22:18 -0700
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> IP_ROUTE_CLASSID depends on INET and NET_CLS_ROUTE4 selects
> IP_ROUTE_CLASSID, but when INET is not enabled, this kconfig warning
> is produced, so fix it by making NET_CLS_ROUTE4 depend on INET.
>
> warning: (NET_CLS_ROUTE4) selects IP_ROUTE_CLASSID which has unmet direct dependencies (NET && INET)
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Applied, thanks Randy.
^ permalink raw reply
* Re: [PATCH] drivers/net: ks8842 Fix crash on received packet when in PIO mode.
From: Dennis Aberilla @ 2011-05-19 23:30 UTC (permalink / raw)
To: David Miller; +Cc: info, netdev
In-Reply-To: <20110519.161228.1163475688237712245.davem@davemloft.net>
On Thu, May 19, 2011 at 04:12:28PM -0400, David Miller wrote:
> From: Dennis Aberilla <dennis.aberilla@mimomax.com>
> Date: Thu, 19 May 2011 10:59:47 +1200
>
> > This patch fixes a kernel crash during packet reception due to not
> > enough allocated bytes for the skb. This applies to the driver when
> > running in PIO mode in an ISA bus setup.
> >
> > Signed-off-by: Dennis Aberilla <denzzzhome@yahoo.com>
>
> If you're trying to accomodate the fact that the loops iterate
> always by 2 or 4 bytes at a time, then you will need to allocate
> up to "3" bytes of slack space, not just "2".
>
> You need to describe exactly what the precise problem is in your
> commit message, or else people might find it difficult to figure
> out exactly what the problem is.
Ah right, it should actually be 3. Yes, it accounts for the fact that the
loops are reading the Rx buffer 4 bytes at a time. Sorry it wasn't too
clear previously.
|Dennis
=======================================================================
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================
^ permalink raw reply
* Re: [PATCH net-next 10/13] tg3: Consolidate all netdev feature assignments
From: Matt Carlson @ 2011-05-19 23:51 UTC (permalink / raw)
To: Mahesh Bandewar; +Cc: Matthew Carlson, David Miller, linux-netdev
In-Reply-To: <BANLkTim7uERxfwd2isfBUbX7WS8-X-Rj9w@mail.gmail.com>
On Thu, May 19, 2011 at 04:15:52PM -0700, Mahesh Bandewar wrote:
> On Thu, May 19, 2011 at 3:12 PM, Matt Carlson <mcarlson@broadcom.com> wrote:
> > This patch consolidates all the netdev feature bit assignments to one
> > location.
> >
> > Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> > Reviewed-by: Michael Chan <mchan@broadcom.com>
> > ---
> > ?drivers/net/tg3.c | ? 51 ++++++++++++++++++++++++---------------------------
> > ?1 files changed, 24 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
> > index 09fe067..5bf2ce1 100644
> > --- a/drivers/net/tg3.c
> > +++ b/drivers/net/tg3.c
> > @@ -13602,19 +13602,6 @@ static int __devinit tg3_get_invariants(struct tg3 *tp)
> > ? ? ? ? ? ?tg3_flag(tp, 5750_PLUS))
> > ? ? ? ? ? ? ? ?tg3_flag_set(tp, 5705_PLUS);
> >
> > - ? ? ? /* 5700 B0 chips do not support checksumming correctly due
> > - ? ? ? ?* to hardware bugs.
> > - ? ? ? ?*/
> > - ? ? ? if (tp->pci_chip_rev_id != CHIPREV_ID_5700_B0) {
> > - ? ? ? ? ? ? ? u32 features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_RXCSUM;
> > -
> > - ? ? ? ? ? ? ? if (tg3_flag(tp, 5755_PLUS))
> > - ? ? ? ? ? ? ? ? ? ? ? features |= NETIF_F_IPV6_CSUM;
> > - ? ? ? ? ? ? ? tp->dev->features |= features;
> > - ? ? ? ? ? ? ? tp->dev->hw_features |= features;
> > - ? ? ? ? ? ? ? tp->dev->vlan_features |= features;
> > - ? ? ? }
> > -
> > ? ? ? ?/* Determine TSO capabilities */
> > ? ? ? ?if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5719)
> > ? ? ? ? ? ? ? ?; /* Do nothing. HW bug. */
> > @@ -14922,7 +14909,7 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
> > ? ? ? ?u32 sndmbx, rcvmbx, intmbx;
> > ? ? ? ?char str[40];
> > ? ? ? ?u64 dma_mask, persist_dma_mask;
> > - ? ? ? u32 hw_features = 0;
> > + ? ? ? u32 features = 0;
> >
> > ? ? ? ?printk_once(KERN_INFO "%s\n", version);
> >
> > @@ -14958,8 +14945,6 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
> >
> > ? ? ? ?SET_NETDEV_DEV(dev, &pdev->dev);
> >
> > - ? ? ? dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
> > -
> > ? ? ? ?tp = netdev_priv(dev);
> > ? ? ? ?tp->pdev = pdev;
> > ? ? ? ?tp->dev = dev;
> > @@ -15039,7 +15024,7 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
> > ? ? ? ?if (dma_mask > DMA_BIT_MASK(32)) {
> > ? ? ? ? ? ? ? ?err = pci_set_dma_mask(pdev, dma_mask);
> > ? ? ? ? ? ? ? ?if (!err) {
> > - ? ? ? ? ? ? ? ? ? ? ? dev->features |= NETIF_F_HIGHDMA;
> > + ? ? ? ? ? ? ? ? ? ? ? features |= NETIF_F_HIGHDMA;
> > ? ? ? ? ? ? ? ? ? ? ? ?err = pci_set_consistent_dma_mask(pdev,
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?persist_dma_mask);
> > ? ? ? ? ? ? ? ? ? ? ? ?if (err < 0) {
> > @@ -15060,6 +15045,18 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
> >
> > ? ? ? ?tg3_init_bufmgr_config(tp);
> >
> > + ? ? ? features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
> > +
> > + ? ? ? /* 5700 B0 chips do not support checksumming correctly due
> > + ? ? ? ?* to hardware bugs.
> > + ? ? ? ?*/
> > + ? ? ? if (tp->pci_chip_rev_id != CHIPREV_ID_5700_B0) {
> > + ? ? ? ? ? ? ? features |= NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_RXCSUM;
> > +
> > + ? ? ? ? ? ? ? if (tg3_flag(tp, 5755_PLUS))
> > + ? ? ? ? ? ? ? ? ? ? ? features |= NETIF_F_IPV6_CSUM;
> > + ? ? ? }
> > +
> > ? ? ? ?/* TSO is on by default on chips that support hardware TSO.
> > ? ? ? ? * Firmware TSO on older chips gives lower performance, so it
> > ? ? ? ? * is off by default, but can be enabled using ethtool.
> > @@ -15067,24 +15064,20 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
> > ? ? ? ?if ((tg3_flag(tp, HW_TSO_1) ||
> > ? ? ? ? ? ? tg3_flag(tp, HW_TSO_2) ||
> > ? ? ? ? ? ? tg3_flag(tp, HW_TSO_3)) &&
> > - ? ? ? ? ? (dev->features & NETIF_F_IP_CSUM))
> > - ? ? ? ? ? ? ? hw_features |= NETIF_F_TSO;
> > + ? ? ? ? ? (features & NETIF_F_IP_CSUM))
> > + ? ? ? ? ? ? ? features |= NETIF_F_TSO;
> > ? ? ? ?if (tg3_flag(tp, HW_TSO_2) || tg3_flag(tp, HW_TSO_3)) {
> > - ? ? ? ? ? ? ? if (dev->features & NETIF_F_IPV6_CSUM)
> > - ? ? ? ? ? ? ? ? ? ? ? hw_features |= NETIF_F_TSO6;
> > + ? ? ? ? ? ? ? if (features & NETIF_F_IPV6_CSUM)
> > + ? ? ? ? ? ? ? ? ? ? ? features |= NETIF_F_TSO6;
> > ? ? ? ? ? ? ? ?if (tg3_flag(tp, HW_TSO_3) ||
> > ? ? ? ? ? ? ? ? ? ?GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5761 ||
> > ? ? ? ? ? ? ? ? ? ?(GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5784 &&
> > ? ? ? ? ? ? ? ? ? ? GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5784_AX) ||
> > ? ? ? ? ? ? ? ? ? ?GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5785 ||
> > ? ? ? ? ? ? ? ? ? ?GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_57780)
> > - ? ? ? ? ? ? ? ? ? ? ? hw_features |= NETIF_F_TSO_ECN;
> > + ? ? ? ? ? ? ? ? ? ? ? features |= NETIF_F_TSO_ECN;
> > ? ? ? ?}
> >
> > - ? ? ? dev->hw_features |= hw_features;
> > - ? ? ? dev->features |= hw_features;
> > - ? ? ? dev->vlan_features |= hw_features;
> > -
> > ? ? ? ?/*
> > ? ? ? ? * Add loopback capability only for a subset of devices that support
> > ? ? ? ? * MAC-LOOPBACK. Eventually this need to be enhanced to allow INT-PHY
> > @@ -15093,7 +15086,11 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
> > ? ? ? ?if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5780 &&
> > ? ? ? ? ? ?!tg3_flag(tp, CPMU_PRESENT))
> > ? ? ? ? ? ? ? ?/* Add the loopback capability */
> > - ? ? ? ? ? ? ? dev->hw_features |= NETIF_F_LOOPBACK;
> > + ? ? ? ? ? ? ? features |= NETIF_F_LOOPBACK;
> > +
> > + ? ? ? dev->features |= features;
> This will set the loopback by default for the described sub-set.
> > + ? ? ? dev->hw_features |= features;
> Yes, you just want to add that here only.
Yes. Good catch. I'll post a follow on patch ASAP.
^ permalink raw reply
* Re: [PATCH V5 2/6 net-next] netdevice.h: Add zero-copy flag in netdevice
From: Michael S. Tsirkin @ 2011-05-19 23:41 UTC (permalink / raw)
To: Shirley Ma
Cc: Michał Mirosław, Ben Hutchings, David Miller,
Eric Dumazet, Avi Kivity, Arnd Bergmann, netdev, kvm,
linux-kernel
In-Reply-To: <1305834169.32080.81.camel@localhost.localdomain>
On Thu, May 19, 2011 at 12:42:49PM -0700, Shirley Ma wrote:
> On Wed, 2011-05-18 at 10:00 -0700, Shirley Ma wrote:
> > On Wed, 2011-05-18 at 19:51 +0300, Michael S. Tsirkin wrote:
> > > > > Yes, I agree. I think for tcpdump, we really need to copy the
> > > data
> > > > > anyway, to avoid guest changing it in between. So we do that
> > and
> > > then
> > > > > use the copy everywhere, release the old one. Hmm?
> > > >
> > > > Yes. Old one use zerocopy, new one use copy data.
> > > >
> > > > Thanks
> > > > Shirley
> > >
> > > No, that's wrong, as they might become different with a
> > > malicious guest. As long as we copied already, lets realease
> > > the data and have everyone use the copy.
> >
> > Ok, I will patch pskb_expand_head to test it out.
>
> I am patching skb_copy, skb_clone, pskb_copy, pskb_expand_head to
> convert a zero-copy skb to a copy skb to avoid this kind of issue.
>
> This overhead won't impact macvtap/vhost TX zero-copy normally.
>
> Shirley
OK, that will handle packet socket at least in that it won't crash :)
So the requirements are
- data must be released in a timely fashion (e.g. unlike virtio-net
tun or bridge)
- no filtering based on data (data is mapped in guest)
- SG support
- HIGHDMA support (on arches where this makes sense)
- on fast path no calls to skb_copy, skb_clone, pskb_copy,
pskb_expand_head as these are slow
First 2 requirements are a must, all other requirements
are just dependencies to make sure zero copy will be faster
than non zero copy.
Using a new feature bit is probably the simplest approach to
this. macvtap on top of most physical NICs most likely works
correctly so it seems a bit more work than it needs to be,
but it's also the safest one I think ...
--
MST
^ permalink raw reply
* Re: TCP funny-ness when over-driving a 1Gbps link.
From: Ben Greear @ 2011-05-19 23:42 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <4DD5A5CD.7040303@candelatech.com>
On 05/19/2011 04:20 PM, Ben Greear wrote:
> On 05/19/2011 04:18 PM, Stephen Hemminger wrote:
>> If you overdrive, TCP expects your network emulator to have
>> a some but limited queueing (like a real router).
>
> The emulator is fine, it's not being over-driven (and has limited
> queueing if it was
> being over-driven). The queues that are backing up are in the tcp
> sockets on the
> sending machine.
>
> But, just to make sure, I'll re-run the test with a looped back cable...
Well, with looped back cable, it isn't so bad. I still see a small drop
in aggregate throughput (around 900Mbps instead of 950Mbps), and
latency goes above 600ms, but it still performs better than when
going through the emulator.
At 950+Mbps, the emulator is going to impart 1-2 ms of latency
even when configured for wide-open.
If I use a bridge in place of the emulator, it seems to settle on
around 450Mbps in one direction and 945Mbps in the other (on the wire),
with round-trip latencies often over 5 seconds (user-space to user-space),
and a consistent large chunk of data in the socket send buffers:
[root@i7-965-1 igb]# netstat -an|grep tcp|grep 8.1.1
tcp 0 0 8.1.1.1:33038 0.0.0.0:* LISTEN
tcp 0 0 8.1.1.1:33040 0.0.0.0:* LISTEN
tcp 0 0 8.1.1.1:33042 0.0.0.0:* LISTEN
tcp 0 9328612 8.1.1.2:33039 8.1.1.1:33040 ESTABLISHED
tcp 0 17083176 8.1.1.1:33038 8.1.1.2:33037 ESTABLISHED
tcp 0 9437340 8.1.1.2:33037 8.1.1.1:33038 ESTABLISHED
tcp 0 17024620 8.1.1.1:33040 8.1.1.2:33039 ESTABLISHED
tcp 0 19557040 8.1.1.1:33042 8.1.1.2:33041 ESTABLISHED
tcp 0 9416600 8.1.1.2:33041 8.1.1.1:33042 ESTABLISHED
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: TCP funny-ness when over-driving a 1Gbps link.
From: Rick Jones @ 2011-05-20 0:05 UTC (permalink / raw)
To: Ben Greear; +Cc: Stephen Hemminger, netdev
In-Reply-To: <4DD5AAFC.8070509@candelatech.com>
On Thu, 2011-05-19 at 16:42 -0700, Ben Greear wrote:
> On 05/19/2011 04:20 PM, Ben Greear wrote:
> > On 05/19/2011 04:18 PM, Stephen Hemminger wrote:
>
> >> If you overdrive, TCP expects your network emulator to have
> >> a some but limited queueing (like a real router).
> >
> > The emulator is fine, it's not being over-driven (and has limited
> > queueing if it was
> > being over-driven). The queues that are backing up are in the tcp
> > sockets on the
> > sending machine.
> >
> > But, just to make sure, I'll re-run the test with a looped back cable...
>
> Well, with looped back cable, it isn't so bad. I still see a small drop
> in aggregate throughput (around 900Mbps instead of 950Mbps), and
> latency goes above 600ms, but it still performs better than when
> going through the emulator.
>
> At 950+Mbps, the emulator is going to impart 1-2 ms of latency
> even when configured for wide-open.
>
> If I use a bridge in place of the emulator, it seems to settle on
> around 450Mbps in one direction and 945Mbps in the other (on the wire),
> with round-trip latencies often over 5 seconds (user-space to user-space),
> and a consistent large chunk of data in the socket send buffers:
>
> [root@i7-965-1 igb]# netstat -an|grep tcp|grep 8.1.1
> tcp 0 0 8.1.1.1:33038 0.0.0.0:* LISTEN
> tcp 0 0 8.1.1.1:33040 0.0.0.0:* LISTEN
> tcp 0 0 8.1.1.1:33042 0.0.0.0:* LISTEN
> tcp 0 9328612 8.1.1.2:33039 8.1.1.1:33040 ESTABLISHED
> tcp 0 17083176 8.1.1.1:33038 8.1.1.2:33037 ESTABLISHED
> tcp 0 9437340 8.1.1.2:33037 8.1.1.1:33038 ESTABLISHED
> tcp 0 17024620 8.1.1.1:33040 8.1.1.2:33039 ESTABLISHED
> tcp 0 19557040 8.1.1.1:33042 8.1.1.2:33041 ESTABLISHED
> tcp 0 9416600 8.1.1.2:33041 8.1.1.1:33042 ESTABLISHED
I take it your system has higher values for the tcp_wmem value:
net.ipv4.tcp_wmem = 4096 16384 4194304
and whatever is creating the TCP connections is not making explicit
setsockopt() calls to set SO_*BUF.
rick jones
^ permalink raw reply
* Re: TCP funny-ness when over-driving a 1Gbps link.
From: Ben Greear @ 2011-05-20 0:12 UTC (permalink / raw)
To: rick.jones2; +Cc: Stephen Hemminger, netdev
In-Reply-To: <1305849940.8149.1122.camel@tardy>
On 05/19/2011 05:05 PM, Rick Jones wrote:
> On Thu, 2011-05-19 at 16:42 -0700, Ben Greear wrote:
>> On 05/19/2011 04:20 PM, Ben Greear wrote:
>>> On 05/19/2011 04:18 PM, Stephen Hemminger wrote:
>>
>>>> If you overdrive, TCP expects your network emulator to have
>>>> a some but limited queueing (like a real router).
>>>
>>> The emulator is fine, it's not being over-driven (and has limited
>>> queueing if it was
>>> being over-driven). The queues that are backing up are in the tcp
>>> sockets on the
>>> sending machine.
>>>
>>> But, just to make sure, I'll re-run the test with a looped back cable...
>>
>> Well, with looped back cable, it isn't so bad. I still see a small drop
>> in aggregate throughput (around 900Mbps instead of 950Mbps), and
>> latency goes above 600ms, but it still performs better than when
>> going through the emulator.
>>
>> At 950+Mbps, the emulator is going to impart 1-2 ms of latency
>> even when configured for wide-open.
>>
>> If I use a bridge in place of the emulator, it seems to settle on
>> around 450Mbps in one direction and 945Mbps in the other (on the wire),
>> with round-trip latencies often over 5 seconds (user-space to user-space),
>> and a consistent large chunk of data in the socket send buffers:
>>
>> [root@i7-965-1 igb]# netstat -an|grep tcp|grep 8.1.1
>> tcp 0 0 8.1.1.1:33038 0.0.0.0:* LISTEN
>> tcp 0 0 8.1.1.1:33040 0.0.0.0:* LISTEN
>> tcp 0 0 8.1.1.1:33042 0.0.0.0:* LISTEN
>> tcp 0 9328612 8.1.1.2:33039 8.1.1.1:33040 ESTABLISHED
>> tcp 0 17083176 8.1.1.1:33038 8.1.1.2:33037 ESTABLISHED
>> tcp 0 9437340 8.1.1.2:33037 8.1.1.1:33038 ESTABLISHED
>> tcp 0 17024620 8.1.1.1:33040 8.1.1.2:33039 ESTABLISHED
>> tcp 0 19557040 8.1.1.1:33042 8.1.1.2:33041 ESTABLISHED
>> tcp 0 9416600 8.1.1.2:33041 8.1.1.1:33042 ESTABLISHED
>
> I take it your system has higher values for the tcp_wmem value:
>
> net.ipv4.tcp_wmem = 4096 16384 4194304
Yes:
[root@i7-965-1 igb]# cat /proc/sys/net/ipv4/tcp_wmem
4096 16384 50000000
> and whatever is creating the TCP connections is not making explicit
> setsockopt() calls to set SO_*BUF.
It is configured not to, but if you know of an independent way to verify
that, I'm interested.
Thanks,
Ben
>
> rick jones
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH net-next-2.6] macvlan: remove one synchronize_rcu() call
From: Ben Greear @ 2011-05-20 0:18 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Patrick McHardy, netdev
In-Reply-To: <1305843856.3156.36.camel@edumazet-laptop>
On 05/19/2011 03:24 PM, Eric Dumazet wrote:
> When one macvlan device is dismantled, we can avoid one
> synchronize_rcu() call done after deletion from hash list, since caller
> will perform a synchronize_net() call after its ndo_stop() call.
>
> Add a new netdev->dismantle field to signal this dismantle intent.
I applied this to today's wireless-testing kernel. There is a consistent
speedup in deleting mac-vlans! I wouldn't read much into changes in
creating macvlans or adding IPs..those numbers just jump around a bit
from run to run.
Before the patch:
[root@lec2010-ath9k-1 lanforge]# /mnt/b32/greearb/tmp/test_macvlans.pl 500 macvlan
Creating 500 macvlan.
Created 500 macvlan in 12.662865 seconds (0.02532573 per interface).
Added IP addresses in 9.104435 seconds (0.01820887 per addr).
Deleted 500 macvlan in 25.424282 seconds. (0.050848564 per interface)
After the patch:
[root@lec2010-ath9k-1 lanforge]# /mnt/b32/greearb/tmp/test_macvlans.pl 500 macvlan
Creating 500 macvlan.
Created 500 macvlan in 12.461308 seconds (0.024922616 per interface).
Added IP addresses in 8.787694 seconds (0.017575388 per addr).
Deleted 500 macvlan in 21.831413 seconds. (0.043662826 per interface)
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: TCP funny-ness when over-driving a 1Gbps link.
From: Rick Jones @ 2011-05-20 0:24 UTC (permalink / raw)
To: Ben Greear; +Cc: Stephen Hemminger, netdev
In-Reply-To: <4DD5B202.7080701@candelatech.com>
> >> [root@i7-965-1 igb]# netstat -an|grep tcp|grep 8.1.1
> >> tcp 0 0 8.1.1.1:33038 0.0.0.0:* LISTEN
> >> tcp 0 0 8.1.1.1:33040 0.0.0.0:* LISTEN
> >> tcp 0 0 8.1.1.1:33042 0.0.0.0:* LISTEN
> >> tcp 0 9328612 8.1.1.2:33039 8.1.1.1:33040 ESTABLISHED
> >> tcp 0 17083176 8.1.1.1:33038 8.1.1.2:33037 ESTABLISHED
> >> tcp 0 9437340 8.1.1.2:33037 8.1.1.1:33038 ESTABLISHED
> >> tcp 0 17024620 8.1.1.1:33040 8.1.1.2:33039 ESTABLISHED
> >> tcp 0 19557040 8.1.1.1:33042 8.1.1.2:33041 ESTABLISHED
> >> tcp 0 9416600 8.1.1.2:33041 8.1.1.1:33042 ESTABLISHED
> >
> > I take it your system has higher values for the tcp_wmem value:
> >
> > net.ipv4.tcp_wmem = 4096 16384 4194304
>
> Yes:
> [root@i7-965-1 igb]# cat /proc/sys/net/ipv4/tcp_wmem
> 4096 16384 50000000
Why?!? Are you trying to get link-rate to Mars or something? (I assume
tcp_rmem is similarly set...) If you are indeed doing one 1 GbE, and no
more than 100ms then the default (?) of 4194304 should have been more
than sufficient.
> > and whatever is creating the TCP connections is not making explicit
> > setsockopt() calls to set SO_*BUF.
>
> It is configured not to, but if you know of an independent way to verify
> that, I'm interested.
You could always strace the code.
rick
^ permalink raw reply
* Re: TCP funny-ness when over-driving a 1Gbps link.
From: Ben Greear @ 2011-05-20 0:37 UTC (permalink / raw)
To: rick.jones2; +Cc: Stephen Hemminger, netdev
In-Reply-To: <1305851079.8149.1127.camel@tardy>
On 05/19/2011 05:24 PM, Rick Jones wrote:
>>>> [root@i7-965-1 igb]# netstat -an|grep tcp|grep 8.1.1
>>>> tcp 0 0 8.1.1.1:33038 0.0.0.0:* LISTEN
>>>> tcp 0 0 8.1.1.1:33040 0.0.0.0:* LISTEN
>>>> tcp 0 0 8.1.1.1:33042 0.0.0.0:* LISTEN
>>>> tcp 0 9328612 8.1.1.2:33039 8.1.1.1:33040 ESTABLISHED
>>>> tcp 0 17083176 8.1.1.1:33038 8.1.1.2:33037 ESTABLISHED
>>>> tcp 0 9437340 8.1.1.2:33037 8.1.1.1:33038 ESTABLISHED
>>>> tcp 0 17024620 8.1.1.1:33040 8.1.1.2:33039 ESTABLISHED
>>>> tcp 0 19557040 8.1.1.1:33042 8.1.1.2:33041 ESTABLISHED
>>>> tcp 0 9416600 8.1.1.2:33041 8.1.1.1:33042 ESTABLISHED
>>>
>>> I take it your system has higher values for the tcp_wmem value:
>>>
>>> net.ipv4.tcp_wmem = 4096 16384 4194304
>>
>> Yes:
>> [root@i7-965-1 igb]# cat /proc/sys/net/ipv4/tcp_wmem
>> 4096 16384 50000000
>
> Why?!? Are you trying to get link-rate to Mars or something? (I assume
> tcp_rmem is similarly set...) If you are indeed doing one 1 GbE, and no
> more than 100ms then the default (?) of 4194304 should have been more
> than sufficient.
Well, we occasionally do tests over emulated links that have several
seconds of delay and may be running multiple Gbps. Either way,
I'd hope that offering extra RAM to a subsystem wouldn't cause it
to go nuts. Assuming this isn't some magical 1Gbps issue, you
could probably hit the same problem with a wifi link and
default tcp_wmem settings...
>>> and whatever is creating the TCP connections is not making explicit
>>> setsockopt() calls to set SO_*BUF.
>>
>> It is configured not to, but if you know of an independent way to verify
>> that, I'm interested.
>
> You could always strace the code.
Yeah...might be easier in this case to just comment out all those calls
and do a quick test. Will be tomorrow before I can get to
that, however..
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: TCP funny-ness when over-driving a 1Gbps link.
From: Rick Jones @ 2011-05-20 0:46 UTC (permalink / raw)
To: Ben Greear; +Cc: Stephen Hemminger, netdev
In-Reply-To: <4DD5B7B3.2000505@candelatech.com>
On Thu, 2011-05-19 at 17:37 -0700, Ben Greear wrote:
> On 05/19/2011 05:24 PM, Rick Jones wrote:
> >>>> [root@i7-965-1 igb]# netstat -an|grep tcp|grep 8.1.1
> >>>> tcp 0 0 8.1.1.1:33038 0.0.0.0:* LISTEN
> >>>> tcp 0 0 8.1.1.1:33040 0.0.0.0:* LISTEN
> >>>> tcp 0 0 8.1.1.1:33042 0.0.0.0:* LISTEN
> >>>> tcp 0 9328612 8.1.1.2:33039 8.1.1.1:33040 ESTABLISHED
> >>>> tcp 0 17083176 8.1.1.1:33038 8.1.1.2:33037 ESTABLISHED
> >>>> tcp 0 9437340 8.1.1.2:33037 8.1.1.1:33038 ESTABLISHED
> >>>> tcp 0 17024620 8.1.1.1:33040 8.1.1.2:33039 ESTABLISHED
> >>>> tcp 0 19557040 8.1.1.1:33042 8.1.1.2:33041 ESTABLISHED
> >>>> tcp 0 9416600 8.1.1.2:33041 8.1.1.1:33042 ESTABLISHED
> >>>
> >>> I take it your system has higher values for the tcp_wmem value:
> >>>
> >>> net.ipv4.tcp_wmem = 4096 16384 4194304
> >>
> >> Yes:
> >> [root@i7-965-1 igb]# cat /proc/sys/net/ipv4/tcp_wmem
> >> 4096 16384 50000000
> >
> > Why?!? Are you trying to get link-rate to Mars or something? (I assume
> > tcp_rmem is similarly set...) If you are indeed doing one 1 GbE, and no
> > more than 100ms then the default (?) of 4194304 should have been more
> > than sufficient.
>
> Well, we occasionally do tests over emulated links that have several
> seconds of delay and may be running multiple Gbps. Either way,
> I'd hope that offering extra RAM to a subsystem wouldn't cause it
> to go nuts.
It has been my experience that the autotuning tends to grow things
beyond the bandwidthXdelay product.
As for several seconds of delay and multiple Gbps - unless you are
shooting the Moon, sounds like bufferbloat?-)
> Assuming this isn't some magical 1Gbps issue, you
> could probably hit the same problem with a wifi link and
> default tcp_wmem settings...
Do you also increase tx queue's for the NIC(s)?
rick
^ permalink raw reply
* [PATCH net-next 2/2] tg3: Add braces around 5906 workaround.
From: Matt Carlson @ 2011-05-20 1:11 UTC (permalink / raw)
To: davem; +Cc: netdev, mcarlson
Commit dabc5c670d3f86d15ee4f42ab38ec5bd2682487d, entitled
"tg3: Move TSO_CAPABLE assignment", moved some TSO flagging code around.
In the process it failed to add braces around an exceptional 5906
condition. This patch fixes the problem.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
---
drivers/net/tg3.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 0b78c5d..1d91b35 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -13707,9 +13707,11 @@ static int __devinit tg3_get_invariants(struct tg3 *tp)
tp->pcie_cap + PCI_EXP_LNKCTL,
&lnkctl);
if (lnkctl & PCI_EXP_LNKCTL_CLKREQ_EN) {
- if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906)
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) ==
+ ASIC_REV_5906) {
tg3_flag_clear(tp, HW_TSO_2);
tg3_flag_clear(tp, TSO_CAPABLE);
+ }
if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5784 ||
GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5761 ||
tp->pci_chip_rev_id == CHIPREV_ID_57780_A0 ||
--
1.7.3.4
^ permalink raw reply related
* [PATCH net-next 1/2] tg3: Fix NETIF_F_LOOPBACK error
From: Matt Carlson @ 2011-05-20 1:11 UTC (permalink / raw)
To: davem; +Cc: netdev, mcarlson
Mahesh Bandewar noticed that the features cleanup in commit
0da0606f493c5cdab74bdcc96b12f4305ad94085, entitled
"tg3: Consolidate all netdev feature assignments", mistakenly sets
NETIF_F_LOOPBACK by default. This patch corrects the error.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
---
drivers/net/tg3.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 012ce70..0b78c5d 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -15080,6 +15080,8 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
features |= NETIF_F_TSO_ECN;
}
+ dev->features |= features;
+
/*
* Add loopback capability only for a subset of devices that support
* MAC-LOOPBACK. Eventually this need to be enhanced to allow INT-PHY
@@ -15090,7 +15092,6 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
/* Add the loopback capability */
features |= NETIF_F_LOOPBACK;
- dev->features |= features;
dev->hw_features |= features;
dev->vlan_features |= features;
--
1.7.3.4
^ permalink raw reply related
* [PATCH net-next 0/2] tg3: Quickfixes
From: Matt Carlson @ 2011-05-20 1:11 UTC (permalink / raw)
To: davem; +Cc: netdev, mcarlson
This patchset applies some quickfixes to the previous patchset.
^ permalink raw reply
* Re: [PATCH net-next 1/2] tg3: Fix NETIF_F_LOOPBACK error
From: Mahesh Bandewar @ 2011-05-20 1:15 UTC (permalink / raw)
To: Matt Carlson; +Cc: David Miller, linux-netdev
In-Reply-To: <1305853864-2135-2-git-send-email-mcarlson@broadcom.com>
On Thu, May 19, 2011 at 6:11 PM, Matt Carlson <mcarlson@broadcom.com> wrote:
> Mahesh Bandewar noticed that the features cleanup in commit
> 0da0606f493c5cdab74bdcc96b12f4305ad94085, entitled
> "tg3: Consolidate all netdev feature assignments", mistakenly sets
> NETIF_F_LOOPBACK by default. This patch corrects the error.
>
> Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> ---
> drivers/net/tg3.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
> index 012ce70..0b78c5d 100644
> --- a/drivers/net/tg3.c
> +++ b/drivers/net/tg3.c
> @@ -15080,6 +15080,8 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
> features |= NETIF_F_TSO_ECN;
> }
>
> + dev->features |= features;
> +
> /*
> * Add loopback capability only for a subset of devices that support
> * MAC-LOOPBACK. Eventually this need to be enhanced to allow INT-PHY
> @@ -15090,7 +15092,6 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
> /* Add the loopback capability */
> features |= NETIF_F_LOOPBACK;
>
> - dev->features |= features;
> dev->hw_features |= features;
> dev->vlan_features |= features;
I think this line should go up too. Otherwise newly created vlan
device(s) will have spurious loopback bit set.
>
> --
> 1.7.3.4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net-next 1/2] tg3: Fix NETIF_F_LOOPBACK error
From: Matt Carlson @ 2011-05-20 1:59 UTC (permalink / raw)
To: Mahesh Bandewar; +Cc: Matthew Carlson, David Miller, linux-netdev
In-Reply-To: <BANLkTi==K_eTcqQ39HwcBcg9AyuMLuhz6w@mail.gmail.com>
On Thu, May 19, 2011 at 06:15:18PM -0700, Mahesh Bandewar wrote:
> On Thu, May 19, 2011 at 6:11 PM, Matt Carlson <mcarlson@broadcom.com> wrote:
> > Mahesh Bandewar noticed that the features cleanup in commit
> > 0da0606f493c5cdab74bdcc96b12f4305ad94085, entitled
> > "tg3: Consolidate all netdev feature assignments", mistakenly sets
> > NETIF_F_LOOPBACK by default. ?This patch corrects the error.
> >
> > Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> > ---
> > ?drivers/net/tg3.c | ? ?3 ++-
> > ?1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
> > index 012ce70..0b78c5d 100644
> > --- a/drivers/net/tg3.c
> > +++ b/drivers/net/tg3.c
> > @@ -15080,6 +15080,8 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
> > ? ? ? ? ? ? ? ? ? ? ? ?features |= NETIF_F_TSO_ECN;
> > ? ? ? ?}
> >
> > + ? ? ? dev->features |= features;
> > +
> > ? ? ? ?/*
> > ? ? ? ? * Add loopback capability only for a subset of devices that support
> > ? ? ? ? * MAC-LOOPBACK. Eventually this need to be enhanced to allow INT-PHY
> > @@ -15090,7 +15092,6 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
> > ? ? ? ? ? ? ? ?/* Add the loopback capability */
> > ? ? ? ? ? ? ? ?features |= NETIF_F_LOOPBACK;
> >
> > - ? ? ? dev->features |= features;
> > ? ? ? ?dev->hw_features |= features;
> > ? ? ? ?dev->vlan_features |= features;
> I think this line should go up too. Otherwise newly created vlan
> device(s) will have spurious loopback bit set.
Yes. You are right. I thought vlan_features functioned like
hw_features.
^ permalink raw reply
* [PATCH net-next v2 1/2] tg3: Fix NETIF_F_LOOPBACK error
From: Matt Carlson @ 2011-05-20 2:02 UTC (permalink / raw)
To: davem; +Cc: netdev, mcarlson, Mahesh Bandewar
Mahesh Bandewar noticed that the features cleanup in commit
0da0606f493c5cdab74bdcc96b12f4305ad94085, entitled
"tg3: Consolidate all netdev feature assignments", mistakenly sets
NETIF_F_LOOPBACK by default. This patch corrects the error.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
drivers/net/tg3.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 012ce70..284e998 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -15080,6 +15080,9 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
features |= NETIF_F_TSO_ECN;
}
+ dev->features |= features;
+ dev->vlan_features |= features;
+
/*
* Add loopback capability only for a subset of devices that support
* MAC-LOOPBACK. Eventually this need to be enhanced to allow INT-PHY
@@ -15090,9 +15093,7 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
/* Add the loopback capability */
features |= NETIF_F_LOOPBACK;
- dev->features |= features;
dev->hw_features |= features;
- dev->vlan_features |= features;
if (tp->pci_chip_rev_id == CHIPREV_ID_5705_A1 &&
!tg3_flag(tp, TSO_CAPABLE) &&
--
1.7.3.4
^ permalink raw reply related
* [PATCH net-next v2 0/2] tg3: Quickfixes
From: Matt Carlson @ 2011-05-20 2:02 UTC (permalink / raw)
To: davem; +Cc: netdev, mcarlson
This patchset applies some quickfixes to the previous patchset.
^ permalink raw reply
* [PATCH net-next v2 2/2] tg3: Add braces around 5906 workaround.
From: Matt Carlson @ 2011-05-20 2:02 UTC (permalink / raw)
To: davem; +Cc: netdev, mcarlson
Commit dabc5c670d3f86d15ee4f42ab38ec5bd2682487d, entitled
"tg3: Move TSO_CAPABLE assignment", moved some TSO flagging code around.
In the process it failed to add braces around an exceptional 5906
condition. This patch fixes the problem.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
---
drivers/net/tg3.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 284e998..db19332 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -13707,9 +13707,11 @@ static int __devinit tg3_get_invariants(struct tg3 *tp)
tp->pcie_cap + PCI_EXP_LNKCTL,
&lnkctl);
if (lnkctl & PCI_EXP_LNKCTL_CLKREQ_EN) {
- if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906)
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) ==
+ ASIC_REV_5906) {
tg3_flag_clear(tp, HW_TSO_2);
tg3_flag_clear(tp, TSO_CAPABLE);
+ }
if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5784 ||
GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5761 ||
tp->pci_chip_rev_id == CHIPREV_ID_57780_A0 ||
--
1.7.3.4
^ permalink raw reply related
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