* Re: [PATCH 04/14] bna: Add Multiple Tx Queue Support
From: Ben Hutchings @ 2011-08-16 21:48 UTC (permalink / raw)
To: Rasesh Mody; +Cc: davem, netdev, adapter_linux_open_src_team, Gurunatha Karaje
In-Reply-To: <1313529591-3718-5-git-send-email-rmody@brocade.com>
On Tue, 2011-08-16 at 14:19 -0700, Rasesh Mody wrote:
> Change details:
> - Add macros bna_prio_allow, bna_default_nw_prio, bna_iscsi_prio,
> bna_is_iscsi_over_cee
> - Added support for multipe Tx queues with a separate iSCSI Tx queue based
> on the default value of iSCSI port number. The feature is supported based
> on the underlying hardware and enabled for DCB (CEE) mode only.
> - Allocate multiple TxQ resource in netdev
> - Implement bnad_tx_select_queue() which enables the correct selection of
> TxQ Id (and tcb). This function is called either by the kernel to channel
> packets to the right TxQ
> - bnad_tx_select_queue() returns priority, while only a few packets during
> transition could have wrong priority, all will be associated with a valid
> non-NULL tcb.
> - Implement bnad_iscsi_tcb_get() and BNAD_IS_ISCSI_PKT() for iSCSI packet
> inspection and retrieval of tcb corresponding to the iSCSI priority.
> - Construction of priority indirection table to be used by bnad to direct
> packets into TxQs
[...]
You probably should implement TX priority classes through the
ndo_setup_tc operation, not ndo_select_queue.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [Bugme-new] [Bug 41192] New: acer aspire one d522 locks up due to NIC
From: Andrew Morton @ 2011-08-16 22:00 UTC (permalink / raw)
To: Jay Cliburn, Chris Snook, Jie Yang; +Cc: bugme-daemon, netdev, willi
In-Reply-To: <bug-41192-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 15 Aug 2011 12:03:56 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=41192
>
> Summary: acer aspire one d522 locks up due to NIC
> Product: Drivers
> Version: 2.5
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: willi@goesgens.de
> Regression: No
>
>
> Created an attachment (id=68882)
> --> (https://bugzilla.kernel.org/attachment.cgi?id=68882)
> dmesg output of whole system run
>
> This netbook is equipped with:
> 06:00.0 Ethernet controller: Atheros Communications AR8152 v2.0 Fast Ethernet
> (rev c1)
> 07:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network
> Adapter (PCI-Express) (rev 01)
>
> if there is a network manager probing the cable NIC for the cable status, the
> whole system locks up completely.
>
> the lockup can be circumvented by:
> - not loading the kernel module for the cable NIC
> - not starting 'network manager' or 'WICD', same problems on both.
> - turning on the systems netboot agent as pointed out by walterav on
> http://phoronix.com/forums/showthread.php?31961-Notes-on-Acer-Aspire-One-522/page7
>
>
> Module Size Used by
> bnep 17346 2
> rfcomm 73852 0
> bluetooth 252589 10 bnep,rfcomm
> binfmt_misc 7588 1
> fuse 70593 1
> synaptics_i2c_rmi4 7979 0
> ath9k 83089 0
> mac80211 248833 1 ath9k
> ath9k_common 2456 1 ath9k
> ath9k_hw 302986 2 ath9k,ath9k_common
> k10temp 3378 0
> uvcvideo 57863 0
> ath 15715 2 ath9k,ath9k_hw
> cfg80211 211736 3 ath9k,mac80211,ath
> atl1c 45270 0
> rfkill 19387 3 bluetooth,cfg80211
> sp5100_tco 5392 0
> i2c_piix4 11482 0
> mac_hid 3645 0
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 41152] New: kernel 3.0 and above fails to handle vlan id 0 (802.1p) packets properly without hardware acceleration
From: Andrew Morton @ 2011-08-16 22:09 UTC (permalink / raw)
To: Jiri Pirko; +Cc: bugme-daemon, netdev, mike.auty
In-Reply-To: <bug-41152-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Sun, 14 Aug 2011 12:48:16 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=41152
>
> Summary: kernel 3.0 and above fails to handle vlan id 0
> (802.1p) packets properly without hardware
> acceleration
> Product: Networking
> Version: 2.5
> Kernel Version: 3.0
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> AssignedTo: acme@ghostprotocols.net
> ReportedBy: mike.auty@gmail.com
> Regression: Yes
>
>
> Hi there,
>
> I recently found that packets tagged with a vlan id of 0 are no longer received
> on the main interface. There were no dmesg entries on the dropped packets. I
> attempted to setup a vlan 0 interface and configure it, but couldn't
> successfully route traffic to the device. I can recreate this on two of the
> three networking devices I have, my guess is that the third does successfully
> handle hardware acceleration of vlan tags.
>
> After a bisection this appears to be related to commit
> bcc6d47903612c3861201cc3a866fb604f26b8b2, which seems to try to merge the
> non-hardware accelerated and hardware accelerated code paths for handling
> vlans. In the process, it appears vlan id 0 (802.1p) packets are no longer
> handled correctly.
>
> Unfortunately I don't know the code paths well enough to figure out what's
> going wrong, but I'd be happy to provide more information, run tests or try out
> patches if it would help, just let me know. Thanks... 5:)
>
> Mike 5:)
^ permalink raw reply
* Webmail Help Desk
From: Webmail Technical Upgrade Team Alert @ 2011-08-16 20:32 UTC (permalink / raw)
Your mailbox has exceeded the storage limit which is 20GB as set by your
administrator, you are currently running on 20.9GB, you may not be able to
send or receive new mail until you re-validate your mailbox. To
re-validate your mailbox please click or visit this link below to update
your account: http://www.spamagent.gofreeserve.com/
Thanks
Webmail Help Desk
© 2011 All Right Reserved
^ permalink raw reply
* Webmail Help Desk
From: Webmail Technical Upgrade Team Alert @ 2011-08-16 20:27 UTC (permalink / raw)
Your mailbox has exceeded the storage limit which is 20GB as set by your
administrator, you are currently running on 20.9GB, you may not be able to
send or receive new mail until you re-validate your mailbox. To
re-validate your mailbox please click or visit this link below to update
your account: http://www.spamagent.gofreeserve.com/
Thanks
Webmail Help Desk
© 2011 All Right Reserved
^ permalink raw reply
* RE: [PATCH 09/14] bna: Ethtool Enhancements and Fix
From: Rasesh Mody @ 2011-08-16 23:26 UTC (permalink / raw)
To: Ben Hutchings
Cc: davem@davemloft.net, netdev@vger.kernel.org,
Adapter Linux Open SRC Team, Gurunatha Karaje
In-Reply-To: <1313530999.2725.58.camel@bwh-desktop>
>From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>Sent: Tuesday, August 16, 2011 2:43 PM
>
>On Tue, 2011-08-16 at 14:19 -0700, Rasesh Mody wrote:
>> Change details:
>> - Set coalescing time out for multiple tx objects.
>> - Use bnad_dim_timer_stop macro in bnad_set_coalesce.
>> - Add tx_skb counters and NAPI debug counters to ethtool stats.
>> - Add rlb stats strings to bnad_net_stats_strings{} array. rlb_stats
>field
>> was added to struct bfi_enet_stats {} but the corresponding name
>structure
>> array for ethtool was not initialized with right strings, even
>though the
>> actual name structure array got expanded. This caused a NULL
>pointer
>> violation and a crash when doing ehtool -S <if_name>.
>> - While setting the ring parameter restore the rx, vlan configuration
>and
>> set rx mode
>> - Indentation fix
>>
>> Signed-off-by: Gurunatha Karaje <gkaraje@brocade.com>
>> Signed-off-by: Rasesh Mody <rmody@brocade.com>
>> ---
>> drivers/net/ethernet/brocade/bna/bnad.c | 21 +++---
>> drivers/net/ethernet/brocade/bna/bnad.h | 10 ++-
>> drivers/net/ethernet/brocade/bna/bnad_ethtool.c | 88
>+++++++++++++++++++----
>> 3 files changed, 92 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/brocade/bna/bnad.c
>b/drivers/net/ethernet/brocade/bna/bnad.c
>> index 11c058e..76bfa19 100644
>> --- a/drivers/net/ethernet/brocade/bna/bnad.c
>> +++ b/drivers/net/ethernet/brocade/bna/bnad.c
>> @@ -2008,12 +2008,15 @@ void
>> bnad_tx_coalescing_timeo_set(struct bnad *bnad)
>> {
>> struct bnad_tx_info *tx_info;
>> + int i;
>>
>> - tx_info = &bnad->tx_info[0];
>> - if (!tx_info->tx)
>> - return;
>> -
>> - bna_tx_coalescing_timeo_set(tx_info->tx, bnad-
>>tx_coalescing_timeo);
>> + for (i = 0; i < bnad->num_tx; i++) {
>> + tx_info = &bnad->tx_info[i];
>> + if (!tx_info->tx)
>> + continue;
>> + bna_tx_coalescing_timeo_set(tx_info->tx,
>> + bnad->tx_coalescing_timeo);
>> + }
>> }
>[...]
>
>Doesn't this need to be done at the same time as patch 04/14 "bna: Add
>Multiple Tx Queue Support"?
Ben,
Thanks for the feedback!
Yes, this is Multiple TXQ related change and will move it to 04/14. Since
ethtool is using it, we thought it would make more sense to do this change
with other ethtool changes.
Rasesh
^ permalink raw reply
* RE: [PATCH 06/14] bna: TX Path and RX Path Changes
From: Rasesh Mody @ 2011-08-16 23:28 UTC (permalink / raw)
To: Ben Hutchings
Cc: davem@davemloft.net, netdev@vger.kernel.org,
Adapter Linux Open SRC Team, Gurunatha Karaje
In-Reply-To: <1313531155.2725.61.camel@bwh-desktop>
>From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>Sent: Tuesday, August 16, 2011 2:46 PM
>
>On Tue, 2011-08-16 at 14:19 -0700, Rasesh Mody wrote:
>> Change details:
>> - Disable and enable interrupts from the same polling context to
>prevent
>> reordering in Rx path.
>> - Add Rx NAPI debug counters.
>> - Make NAPI budget check more generic
>> - Add a macro bnad_dim_timer_stop for DIM(Dynamic Interrupt
>Moderation)
>> timer stop
>> - Handle reduced MSI-X vectors case in bnad_enable_msix
>> - Replace existing checks with macros and add more checks for illegal
>skbs
>> in transmit path. Add more tx_skb counters for dropped skbs.
>> - Check for single frame TSO skbs and send them out as non-TSO.
>> - Put memory barrier after bna_txq_prod_indx_doorbell()
>>
>> Signed-off-by: Gurunatha Karaje <gkaraje@brocade.com>
>> Signed-off-by: Rasesh Mody <rmody@brocade.com>
>> ---
>> drivers/net/ethernet/brocade/bna/bnad.c | 207 +++++++++++++++++-----
>---------
>> drivers/net/ethernet/brocade/bna/bnad.h | 33 +++++-
>> 2 files changed, 148 insertions(+), 92 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/brocade/bna/bnad.c
>b/drivers/net/ethernet/brocade/bna/bnad.c
>> index 64e2106..0faa8a1 100644
>> --- a/drivers/net/ethernet/brocade/bna/bnad.c
>> +++ b/drivers/net/ethernet/brocade/bna/bnad.c
>> @@ -532,7 +532,7 @@ bnad_poll_cq(struct bnad *bnad, struct bna_ccb
>*ccb, int budget)
>> (flags & BNA_CQ_EF_L4_CKSUM_OK)))
>> skb->ip_summed = CHECKSUM_UNNECESSARY;
>> else
>> - skb_checksum_none_assert(skb);
>> + skb->ip_summed = CHECKSUM_NONE;
>>
>> rcb->rxq->rx_packets++;
>> rcb->rxq->rx_bytes += skb->len;
>[...]
>
>This is reverting part of:
>
>commit bc8acf2c8c3e43fcc192762a9f964b3e9a17748b
>Author: Eric Dumazet <eric.dumazet@gmail.com>
>Date: Thu Sep 2 13:07:41 2010 -0700
>
> drivers/net: avoid some skb->ip_summed initializations
>
>and I don't see any justification for that.
It is an erroneous change, this change will be dropped when resubmitting
this patch set.
Thanks,
Rasesh
^ permalink raw reply
* Re: [PATCH] sit tunnels: propagate IPv6 transport class to IPv4 Type of Service
From: David Miller @ 2011-08-16 23:30 UTC (permalink / raw)
To: lionel; +Cc: pekkas, yoshfuji, kuznet, jmorris, kaber, netdev, linux-kernel
In-Reply-To: <20110814000438.GA30127@capsaicin.mamane.lu>
From: Lionel Elie Mamane <lionel@mamane.lu>
Date: Sun, 14 Aug 2011 02:04:38 +0200
> sit tunnels (IPv6 tunnel over IPv4) do not implement the "tos inherit"
> case to copy the IPv6 transport class byte from the inner packet to
> the IPv4 type of service byte in the outer packet. By contrast, ipip
> tunnels and GRE tunnels do.
>
> This patch, adapted from the similar code in net/ipv4/ipip.c and
> net/ipv4/ip_gre.c, implements that.
>
> This patch applies to 3.0.1, and has been tested on that version.
>
>
> Signed-off-by: Lionel Elie Mamane <lionel@mamane.lu>
Applied, thanks.
^ permalink raw reply
* RE: [PATCH 04/14] bna: Add Multiple Tx Queue Support
From: Rasesh Mody @ 2011-08-16 23:32 UTC (permalink / raw)
To: Ben Hutchings
Cc: davem@davemloft.net, netdev@vger.kernel.org,
Adapter Linux Open SRC Team, Gurunatha Karaje
In-Reply-To: <1313531338.2725.63.camel@bwh-desktop>
>From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>Sent: Tuesday, August 16, 2011 2:49 PM
>
>On Tue, 2011-08-16 at 14:19 -0700, Rasesh Mody wrote:
>> Change details:
>> - Add macros bna_prio_allow, bna_default_nw_prio, bna_iscsi_prio,
>> bna_is_iscsi_over_cee
>> - Added support for multipe Tx queues with a separate iSCSI Tx queue
>based
>> on the default value of iSCSI port number. The feature is supported
>based
>> on the underlying hardware and enabled for DCB (CEE) mode only.
>> - Allocate multiple TxQ resource in netdev
>> - Implement bnad_tx_select_queue() which enables the correct
>selection of
>> TxQ Id (and tcb). This function is called either by the kernel to
>channel
>> packets to the right TxQ
>> - bnad_tx_select_queue() returns priority, while only a few packets
>during
>> transition could have wrong priority, all will be associated with a
>valid
>> non-NULL tcb.
>> - Implement bnad_iscsi_tcb_get() and BNAD_IS_ISCSI_PKT() for iSCSI
>packet
>> inspection and retrieval of tcb corresponding to the iSCSI
>priority.
>> - Construction of priority indirection table to be used by bnad to
>direct
>> packets into TxQs
>[...]
>
>You probably should implement TX priority classes through the
>ndo_setup_tc operation, not ndo_select_queue.
The reason we went with ndo_select_queue is due to the need for mapping
iSCSI packets (TCP port 3260) to a priority derived from DCB configuration.
Here the iSCSI packets may not have any tc defined in the packet header.
Thanks,
Rasesh
^ permalink raw reply
* Re: [PATCH net-next 1/5] ethtool: Reformat struct ethtool_coalesce comments into kernel-doc format
From: David Miller @ 2011-08-16 23:36 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, eli
In-Reply-To: <1313453180.2731.57.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 16 Aug 2011 01:06:20 +0100
> This reorders and duplicates some wording, but should make no
> substantive changes.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/5] ethtool: Specify what kind of coalescing struct ethtool_coalesce covers
From: David Miller @ 2011-08-16 23:36 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, eli
In-Reply-To: <1313453235.2731.58.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 16 Aug 2011 01:07:15 +0100
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 3/5] ethtool: Correct description of 'max_coalesced_frames' fields
From: David Miller @ 2011-08-16 23:36 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, eli
In-Reply-To: <1313453267.2731.59.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 16 Aug 2011 01:07:47 +0100
> The current descriptions state that these fields specify 'How many
> packets to delay ... after a packet ...' which implies that the
> hardware should wait for (max_coalesced_frames + 1) completions before
> generating an interrupt. It is also stated that setting both this
> field and the corresponding 'coalesce_usecs' field to 0 is invalid.
> Together, this implies that the hardware must always be configured
> to delay a completion IRQ for at least 1 usec or 1 more completion.
>
> I believe that the addition of 1 is not intended, and David Miller
> confirms that the original implementation (in tg3) does not do this.
> Clarify the descriptions of these fields to avoid this interpretation.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 4/5] ethtool: Explicitly state the exit condition for interrupt coalescing
From: David Miller @ 2011-08-16 23:36 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, eli
In-Reply-To: <1313453317.2731.60.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 16 Aug 2011 01:08:37 +0100
> Also explicitly state how to disable interrupt coalescing.
>
> Remove the now-redundant text from field descriptions.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 5/5] ethtool: Note common alternate exit condition for interrupt coalescing
From: David Miller @ 2011-08-16 23:36 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, eli
In-Reply-To: <1313453362.2731.61.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 16 Aug 2011 01:09:22 +0100
> Many implementations ignore the value of max_frames and do not
> treat usecs == 0 as special. Document this as deprecated.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* RE: [PATCH 04/14] bna: Add Multiple Tx Queue Support
From: Ben Hutchings @ 2011-08-16 23:43 UTC (permalink / raw)
To: Rasesh Mody
Cc: davem@davemloft.net, netdev@vger.kernel.org,
Adapter Linux Open SRC Team, Gurunatha Karaje
In-Reply-To: <E5313AF6F2BFD14293E5FD0F94750F86A94D99537C@HQ1-EXCH01.corp.brocade.com>
On Tue, 2011-08-16 at 16:32 -0700, Rasesh Mody wrote:
> >From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> >Sent: Tuesday, August 16, 2011 2:49 PM
> >
> >On Tue, 2011-08-16 at 14:19 -0700, Rasesh Mody wrote:
> >> Change details:
> >> - Add macros bna_prio_allow, bna_default_nw_prio, bna_iscsi_prio,
> >> bna_is_iscsi_over_cee
> >> - Added support for multipe Tx queues with a separate iSCSI Tx queue
> >based
> >> on the default value of iSCSI port number. The feature is supported
> >based
> >> on the underlying hardware and enabled for DCB (CEE) mode only.
> >> - Allocate multiple TxQ resource in netdev
> >> - Implement bnad_tx_select_queue() which enables the correct
> >selection of
> >> TxQ Id (and tcb). This function is called either by the kernel to
> >channel
> >> packets to the right TxQ
> >> - bnad_tx_select_queue() returns priority, while only a few packets
> >during
> >> transition could have wrong priority, all will be associated with a
> >valid
> >> non-NULL tcb.
> >> - Implement bnad_iscsi_tcb_get() and BNAD_IS_ISCSI_PKT() for iSCSI
> >packet
> >> inspection and retrieval of tcb corresponding to the iSCSI
> >priority.
> >> - Construction of priority indirection table to be used by bnad to
> >direct
> >> packets into TxQs
> >[...]
> >
> >You probably should implement TX priority classes through the
> >ndo_setup_tc operation, not ndo_select_queue.
>
> The reason we went with ndo_select_queue is due to the need for mapping
> iSCSI packets (TCP port 3260) to a priority derived from DCB configuration.
> Here the iSCSI packets may not have any tc defined in the packet header.
There is an skb priority, which is derived from the socket priority
option (SO_PRIORITY). If you implement ndo_setup_tc then the networking
core will take care of mapping the skb priority onto a different queue
(or range of queues).
I don't know whether the socket priority option is easily configurable
for the existing iSCSI implementations. But looking at port numbers
really doesn't seem like the right way to do this.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* linux-next: boot test failure (net tree)
From: Stephen Rothwell @ 2011-08-17 0:01 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Jeff Kirsher
[-- Attachment #1: Type: text/plain, Size: 761 bytes --]
Hi all,
I do build and boot tests for various PowerPC servers I have access to.
Last night's test failed due to the fact that their ethernet drivers are
not longer being built. In particular, CONFIG_TIGON3 newly depends on
CONFIG_NET_VENDOR_BROADCOM which will no be selected when doing a "make
oldconfig" from a working config. Similarly for CONFIG_IBM_VETH and (the
new) CONFIG_VENDOR_IBM. The original config had both CONFIG_TIGON3 and
CONFIG_IBM_VETH set (to y and m resp.) and the final config had neither.
These Kconfig changes need to be revised so that "make oldconfig" from a
working config builds the same set of drivers ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: David Miller @ 2011-08-17 0:15 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, jeffrey.t.kirsher
In-Reply-To: <20110817100146.3b557cf815a5a2ae09bc09a7@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 17 Aug 2011 10:01:46 +1000
> In particular, CONFIG_TIGON3 newly depends on
> CONFIG_NET_VENDOR_BROADCOM which will no be selected when doing a
> "make oldconfig" from a working config.
When you type "make oldconfig" with an existing .config it prompts you
for those vendor guards, giving you ample opportunity to say yes to
them.
^ permalink raw reply
* Re: [PATCH 04/14] bna: Add Multiple Tx Queue Support
From: John Fastabend @ 2011-08-17 0:17 UTC (permalink / raw)
To: Ben Hutchings
Cc: Rasesh Mody, davem@davemloft.net, netdev@vger.kernel.org,
Adapter Linux Open SRC Team, Gurunatha Karaje
In-Reply-To: <1313538196.2725.74.camel@bwh-desktop>
On 8/16/2011 4:43 PM, Ben Hutchings wrote:
> On Tue, 2011-08-16 at 16:32 -0700, Rasesh Mody wrote:
>>> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>>> Sent: Tuesday, August 16, 2011 2:49 PM
>>>
>>> On Tue, 2011-08-16 at 14:19 -0700, Rasesh Mody wrote:
>>>> Change details:
>>>> - Add macros bna_prio_allow, bna_default_nw_prio, bna_iscsi_prio,
>>>> bna_is_iscsi_over_cee
>>>> - Added support for multipe Tx queues with a separate iSCSI Tx queue
>>> based
>>>> on the default value of iSCSI port number. The feature is supported
>>> based
>>>> on the underlying hardware and enabled for DCB (CEE) mode only.
>>>> - Allocate multiple TxQ resource in netdev
>>>> - Implement bnad_tx_select_queue() which enables the correct
>>> selection of
>>>> TxQ Id (and tcb). This function is called either by the kernel to
>>> channel
>>>> packets to the right TxQ
>>>> - bnad_tx_select_queue() returns priority, while only a few packets
>>> during
>>>> transition could have wrong priority, all will be associated with a
>>> valid
>>>> non-NULL tcb.
>>>> - Implement bnad_iscsi_tcb_get() and BNAD_IS_ISCSI_PKT() for iSCSI
>>> packet
>>>> inspection and retrieval of tcb corresponding to the iSCSI
>>> priority.
>>>> - Construction of priority indirection table to be used by bnad to
>>> direct
>>>> packets into TxQs
>>> [...]
>>>
>>> You probably should implement TX priority classes through the
>>> ndo_setup_tc operation, not ndo_select_queue.
>>
>> The reason we went with ndo_select_queue is due to the need for mapping
>> iSCSI packets (TCP port 3260) to a priority derived from DCB configuration.
>> Here the iSCSI packets may not have any tc defined in the packet header.
>
> There is an skb priority, which is derived from the socket priority
> option (SO_PRIORITY). If you implement ndo_setup_tc then the networking
> core will take care of mapping the skb priority onto a different queue
> (or range of queues).
>
> I don't know whether the socket priority option is easily configurable
> for the existing iSCSI implementations. But looking at port numbers
> really doesn't seem like the right way to do this.
>
> Ben.
>
At least open-iscsi supports DCB by listening to the RTNLGRP_DCB for events.
These are generated with dcbnl_cee_notify and dcbnl_ieee_notify. To support
this in your driver you need to call dcb_setapp() or dcb_ieee_setapp() to
add the application data and follow this with the appropriate notify call.
Then assuming you do the necessary tc setup work the stack will handle the
mapping of priority to queues.
John.
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: Stephen Rothwell @ 2011-08-17 0:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-next, linux-kernel, jeffrey.t.kirsher
In-Reply-To: <20110816.171525.639251389938336183.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 803 bytes --]
Hi Dave,
On Tue, 16 Aug 2011 17:15:25 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 17 Aug 2011 10:01:46 +1000
>
> > In particular, CONFIG_TIGON3 newly depends on
> > CONFIG_NET_VENDOR_BROADCOM which will no be selected when doing a
> > "make oldconfig" from a working config.
>
> When you type "make oldconfig" with an existing .config it prompts you
> for those vendor guards, giving you ample opportunity to say yes to
> them.
Which is a bit of a pain for automated systems. Ours does (essentially):
yes '' | make oldconfig
We really don't want to select every new config item that comes along.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: David Miller @ 2011-08-17 0:56 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, jeffrey.t.kirsher
In-Reply-To: <20110817105002.efebf85d08460ad99b14be8e@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 17 Aug 2011 10:50:02 +1000
> Which is a bit of a pain for automated systems. Ours does (essentially):
>
> yes '' | make oldconfig
>
> We really don't want to select every new config item that comes along.
If you're indeed piping "yes" output to "make oldconfig" on an
existing config, it would select the new guards for you.
This happens on other occaisions, I see new group guards all
the time when I resync my net and net-next trees with Linus.
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: Ben Hutchings @ 2011-08-17 1:19 UTC (permalink / raw)
To: David Miller; +Cc: sfr, netdev, linux-next, linux-kernel, jeffrey.t.kirsher
In-Reply-To: <20110816.175657.1688139393736610845.davem@davemloft.net>
On Tue, 2011-08-16 at 17:56 -0700, David Miller wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 17 Aug 2011 10:50:02 +1000
>
> > Which is a bit of a pain for automated systems. Ours does (essentially):
> >
> > yes '' | make oldconfig
> >
> > We really don't want to select every new config item that comes along.
>
> If you're indeed piping "yes" output to "make oldconfig" on an
> existing config, it would select the new guards for you.
[....]
If you were to use just "yes", then of course it would. But since there
is no explicit default, "yes ''" will deselect them.
Maybe these guards should have "default y"?
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: Stephen Rothwell @ 2011-08-17 1:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-next, linux-kernel, jeffrey.t.kirsher
In-Reply-To: <20110816.175657.1688139393736610845.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 964 bytes --]
Hi Dave,
On Tue, 16 Aug 2011 17:56:57 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 17 Aug 2011 10:50:02 +1000
>
> > Which is a bit of a pain for automated systems. Ours does (essentially):
> >
> > yes '' | make oldconfig
> >
> > We really don't want to select every new config item that comes along.
>
> If you're indeed piping "yes" output to "make oldconfig" on an
> existing config, it would select the new guards for you.
Notice the '' that just is the same as typing return to every prompt. In
the case of these new gueards, that means 'n'. This will be the same
with "make silentoldconfig".
> This happens on other occaisions, I see new group guards all
> the time when I resync my net and net-next trees with Linus.
"All the time"? really?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* RE: [PATCH 04/14] bna: Add Multiple Tx Queue Support
From: Rasesh Mody @ 2011-08-17 2:14 UTC (permalink / raw)
To: John Fastabend, Ben Hutchings
Cc: davem@davemloft.net, netdev@vger.kernel.org,
Adapter Linux Open SRC Team, Gurunatha Karaje
In-Reply-To: <4E4B089E.9080102@intel.com>
>From: John Fastabend [mailto:john.r.fastabend@intel.com]
>Sent: Tuesday, August 16, 2011 5:18 PM
>
>On 8/16/2011 4:43 PM, Ben Hutchings wrote:
>> On Tue, 2011-08-16 at 16:32 -0700, Rasesh Mody wrote:
>>>> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>>>> Sent: Tuesday, August 16, 2011 2:49 PM
>>>>
>>>> On Tue, 2011-08-16 at 14:19 -0700, Rasesh Mody wrote:
>>>>> Change details:
>>>>> - Add macros bna_prio_allow, bna_default_nw_prio, bna_iscsi_prio,
>>>>> bna_is_iscsi_over_cee
>>>>> - Added support for multipe Tx queues with a separate iSCSI Tx
>queue
>>>> based
>>>>> on the default value of iSCSI port number. The feature is
>supported
>>>> based
>>>>> on the underlying hardware and enabled for DCB (CEE) mode only.
>>>>> - Allocate multiple TxQ resource in netdev
>>>>> - Implement bnad_tx_select_queue() which enables the correct
>>>> selection of
>>>>> TxQ Id (and tcb). This function is called either by the kernel
>to
>>>> channel
>>>>> packets to the right TxQ
>>>>> - bnad_tx_select_queue() returns priority, while only a few
>packets
>>>> during
>>>>> transition could have wrong priority, all will be associated
>with a
>>>> valid
>>>>> non-NULL tcb.
>>>>> - Implement bnad_iscsi_tcb_get() and BNAD_IS_ISCSI_PKT() for iSCSI
>>>> packet
>>>>> inspection and retrieval of tcb corresponding to the iSCSI
>>>> priority.
>>>>> - Construction of priority indirection table to be used by bnad to
>>>> direct
>>>>> packets into TxQs
>>>> [...]
>>>>
>>>> You probably should implement TX priority classes through the
>>>> ndo_setup_tc operation, not ndo_select_queue.
>>>
>>> The reason we went with ndo_select_queue is due to the need for
>mapping
>>> iSCSI packets (TCP port 3260) to a priority derived from DCB
>configuration.
>>> Here the iSCSI packets may not have any tc defined in the packet
>header.
>>
>> There is an skb priority, which is derived from the socket priority
>> option (SO_PRIORITY). If you implement ndo_setup_tc then the
>networking
>> core will take care of mapping the skb priority onto a different queue
>> (or range of queues).
>>
>> I don't know whether the socket priority option is easily configurable
>> for the existing iSCSI implementations. But looking at port numbers
>> really doesn't seem like the right way to do this.
>>
>> Ben.
>>
>
>At least open-iscsi supports DCB by listening to the RTNLGRP_DCB for
>events.
>These are generated with dcbnl_cee_notify and dcbnl_ieee_notify. To
>support
>this in your driver you need to call dcb_setapp() or dcb_ieee_setapp()
>to
>add the application data and follow this with the appropriate notify
>call.
>Then assuming you do the necessary tc setup work the stack will handle
>the
>mapping of priority to queues.
This is how iSCSI over DCB feature is expected to works in BNA driver:-
FW running in the BNA adapter implements the DCB protocol. It learns the
iSCSI priority from the switch through iSCSI TLV exchange. BNA driver
extracts the iSCSI priority from the FW that needs to be used for iSCSI
packets. For every outgoing packet, BNA driver does a TCP header
inspection to classify iSCSI packet and attach right 802.1q priority &
send it on the correct TX queue.
This is expected to work with iSCSI applications that do not configure the
priority with SO_PRIORITY - here the iSCSI priority configuration actually
comes from the switch to the adapter.
The goal of this iSCSI priority is:
a) adapter applies prioritized scheduling for packets in its egress - to
guarantee minimum bandwidth as per ETS
b) packets are tagged with right priority so that switch can also identify
and guarantee BW on its egress.
Hope this explains.
Thanks,
Rasesh
^ permalink raw reply
* Attention
From: Mr.Sani Mohammed @ 2011-08-17 1:26 UTC (permalink / raw)
I wrote to know if this is your valid email. Please, let me know if
this Email is valid. I have information to pass to you. The G-20
meeting that was hold recently in France has appointed you through an
email electronic ballot system selection. That makes you the beneficiary
of 1.2 Million USD, in this year?s annual financial meeting for the
development
of your geographical area that will enhance the economic growth of the
society.
Please confirm your email to the G-20 Secretarial in Malaysia.
Please notify us if your email is valid by providing the below details.
Full Name:
Country:
Email: sani_moh9090@yahoo.com.my
Mr.Sani Mohammed
Tele: +601116300759
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: David Miller @ 2011-08-17 3:04 UTC (permalink / raw)
To: bhutchings; +Cc: sfr, netdev, linux-next, linux-kernel, jeffrey.t.kirsher
In-Reply-To: <1313543952.2981.132.camel@deadeye>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 17 Aug 2011 02:19:12 +0100
> If you were to use just "yes", then of course it would. But since there
> is no explicit default, "yes ''" will deselect them.
>
> Maybe these guards should have "default y"?
The point is to declutter xconfig and friends, if it defaults to
'y' everything will just always expand.
^ 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