From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
To: Jimmy PERCHET <jimmy.perchet@parrot.com>
Cc: <netdev@vger.kernel.org>, <jimmy.perchet@gmail.com>
Subject: Re: [PATCH RFC 4/5] net:stmmac: fix jumbo frame handling.
Date: Tue, 22 Oct 2013 15:24:06 +0200 [thread overview]
Message-ID: <52667C76.4080305@st.com> (raw)
In-Reply-To: <52655640.4060405@parrot.com>
On 10/21/2013 6:28 PM, Jimmy PERCHET wrote:
> On 21/10/2013 15:40, Giuseppe CAVALLARO wrote:
>> On 10/16/2013 5:24 PM, Jimmy Perchet wrote:
>>> This patch addresses several issues which prevent jumbo frames from working properly :
>>> .jumbo frames' last descriptor was not closed
>>> .several confusion regarding descriptor's max buffer size
>>> .frags could not be jumbo
>>>
>>> Signed-off-by: Jimmy Perchet <jimmy.perchet@parrot.com>
>>
>>
>> Jimmy, thx for thi patch. BElow some my first notes.
>
> Thanks a lot for this first review.
welcome
>
>> I'll continue to look at the patch to verify if I missed
>> soemthing. I kindly ask you, for the next version, to add
>> more comments especially in the function to prepare the
>> tx desc in order to help me on reviewing.
>
> Sure ;)
>
> I hope do v2 by next week.
ok thx, I'll try to help on reviewing for the v2 again.
>
> I'm OK with most of your comments. Some additional
> notes below:
>
>>> }
>>> @@ -81,7 +81,7 @@ static inline void ndesc_end_tx_desc_on_ring(struct dma_desc *p, int ter)
>>>
>>> static inline void norm_set_tx_desc_len_on_ring(struct dma_desc *p, int len)
>>> {
>>> - if (unlikely(len > BUF_SIZE_2KiB)) {
>>> + if (unlikely(len >= BUF_SIZE_2KiB)) {
>>
>> we cannot manage a size of 2048 on normal desc
>>
>> Pls you should verify to not break the back-compatibility.
>
> IMHO, this actually fix the problem you think I create.
> In current code, if len is equal to 2048, buffer1_size is set to 2048,
> this is wrong because the max size is actually 2047...
IIRC, for normal descriptors, the TBS2/1 are just 11 bits
so the max programmable size is 2047 (0x7ff).
>
>>
>>> p->des01.etx.buffer1_size = BUF_SIZE_2KiB - 1;
>>> p->des01.etx.buffer2_size = len - p->des01.etx.buffer1_size;
>>> } else
>
>
>
>>>
>>> static void stmmac_refill_desc3(void *priv_ptr, struct dma_desc *p)
>>> {
>>> @@ -103,13 +90,13 @@ static void stmmac_refill_desc3(void *priv_ptr, struct dma_desc *p)
>>> if (unlikely(priv->plat->has_gmac))
>>> /* Fill DES3 in case of RING mode */
>>> if (priv->dma_buf_sz >= BUF_SIZE_8KiB)
>>> - p->des3 = p->des2 + BUF_SIZE_8KiB;
>>> + p->des3 = p->des2 + BUF_SIZE_8KiB - 1;
>>
>> is it correct? can you check?
>
> The actual buffer's max size is 8191, so, in ring mode,
> the second buffer must start at p->des2 + 8191.
>
>>> - priv->cur_tx++;
>>> + priv->cur_tx += nb_desc;
>>
>> can we avoid to use the nb_desc?
> Actually, it is a preparation for my 5th patch : I want to write cur_tx only once.
> I can split this.
ok
>
>
>
> Best Regards,
> Jimmy
>
>
next prev parent reply other threads:[~2013-10-22 13:24 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-16 15:24 [PATCH RFC 0/5] net:stmmac: fix jumbo frames handling and optimisation Jimmy Perchet
2013-10-16 15:24 ` [PATCH RFC 1/5] net:stmmac: set threshold/store and forward mode according to mtu size Jimmy Perchet
2013-10-21 8:47 ` Giuseppe CAVALLARO
2013-10-21 9:58 ` Rayagond K
2013-10-21 13:49 ` Giuseppe CAVALLARO
2013-10-16 15:24 ` [PATCH RFC 2/5] net:stmmac: fix rx buffer allocation Jimmy Perchet
2013-10-21 8:54 ` Giuseppe CAVALLARO
2013-10-16 15:24 ` [PATCH RFC 3/5] net:stmmac: ensure we reclaim all dirty descriptors Jimmy Perchet
2013-10-16 17:46 ` Sergei Shtylyov
2013-10-18 8:32 ` Jimmy PERCHET
2013-10-21 9:07 ` Giuseppe CAVALLARO
2013-10-21 13:10 ` Jimmy PERCHET
2013-10-21 18:32 ` Eric Dumazet
2013-10-21 18:49 ` Eric Dumazet
2013-10-22 13:33 ` Giuseppe CAVALLARO
2013-10-16 15:24 ` [PATCH RFC 4/5] net:stmmac: fix jumbo frame handling Jimmy Perchet
2013-10-21 13:40 ` Giuseppe CAVALLARO
2013-10-21 16:28 ` Jimmy PERCHET
2013-10-22 13:24 ` Giuseppe CAVALLARO [this message]
2013-10-16 15:24 ` [PATCH RFC 5/5] net:stmmac: asynchronous tx_clean Jimmy Perchet
2013-10-21 13:52 ` Giuseppe CAVALLARO
2013-10-21 16:30 ` Eric Dumazet
2013-10-21 18:05 ` Jimmy PERCHET
2013-10-21 18:24 ` Eric Dumazet
2013-10-16 20:37 ` [PATCH RFC 0/5] net:stmmac: fix jumbo frames handling and optimisation Giuseppe CAVALLARO
2013-10-18 16:24 ` Jimmy PERCHET
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52667C76.4080305@st.com \
--to=peppe.cavallaro@st.com \
--cc=jimmy.perchet@gmail.com \
--cc=jimmy.perchet@parrot.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).