On 9/30/2014 9:24 PM, Eric Dumazet wrote:
On Tue, 2014-09-30 at 20:14 -0700, Prashant wrote:
Sorry about the late reply, out of all the HW bug conditions checked in
tg3_tx_frag_set() the most frequently hit condition is the short 8 byte
dma bug, where the chip cannot handle TX descriptors who
On Tue, 2014-09-30 at 20:14 -0700, Prashant wrote:
> Sorry about the late reply, out of all the HW bug conditions checked in
> tg3_tx_frag_set() the most frequently hit condition is the short 8 byte
> dma bug, where the chip cannot handle TX descriptors whose data buffer
> is 8 bytes or less. M
On 9/5/2014 9:39 PM, David Miller wrote:
From: David Miller
Date: Fri, 05 Sep 2014 17:13:06 -0700 (PDT)
From: Eric Dumazet
Date: Fri, 05 Sep 2014 17:03:30 -0700
Instead of this private helper (and pretty limited one btw), we could
add a core function, that would build skbs with order-0 fr
From: David Miller
Date: Fri, 05 Sep 2014 17:13:06 -0700 (PDT)
> From: Eric Dumazet
> Date: Fri, 05 Sep 2014 17:03:30 -0700
>
>> Instead of this private helper (and pretty limited one btw), we could
>> add a core function, that would build skbs with order-0 fragments.
>>
>> Instead of skb_line
From: Eric Dumazet
Date: Fri, 05 Sep 2014 17:03:30 -0700
> Instead of this private helper (and pretty limited one btw), we could
> add a core function, that would build skbs with order-0 fragments.
>
> Instead of skb_linearize(), I guess many call sites could instead use
> this new helper.
>
>
On Fri, 2014-09-05 at 16:35 -0700, Prashant Sreedharan wrote:
> fyi.. Initially the driver was doing a skb_copy()
> (tigon3_dma_hwbug_workaround()) for LSO skb that met HW bug conditions
> but users started reporting page allocation failures due to copying of
> large LSO skbs. To avoid this Commit
> static int tg3_tso_bug(struct tg3 *tp, struct tg3_napi *tnapi,
> struct netdev_queue *txq, struct sk_buff *skb)
> {
> - struct sk_buff *segs, *nskb;
> - u32 frag_cnt_est = skb_shinfo(skb)->gso_segs * 3;
> + unsigned int segs_remaining = skb_shinfo(skb)->gso_seg
In tg3_set_ringparam(), the tx_pending test to cover the cases where
tg3_tso_bug() is entered has two problems
1) the check is only done for certain hardware whereas the workaround
is now used more broadly. IOW, the check may not be performed when it
is needed.
2) the check is too optimistic.
For
8 matches
Mail list logo
