From: Jimmy PERCHET <jimmy.perchet@parrot.com>
To: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Cc: <netdev@vger.kernel.org>, <jimmy.perchet@gmail.com>
Subject: Re: [PATCH RFC 4/5] net:stmmac: fix jumbo frame handling.
Date: Mon, 21 Oct 2013 18:28:48 +0200 [thread overview]
Message-ID: <52655640.4060405@parrot.com> (raw)
In-Reply-To: <52652EE7.2060500@st.com>
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.
> 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.
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...
>
>> 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.
Best Regards,
Jimmy
next prev parent reply other threads:[~2013-10-21 16:28 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 [this message]
2013-10-22 13:24 ` Giuseppe CAVALLARO
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=52655640.4060405@parrot.com \
--to=jimmy.perchet@parrot.com \
--cc=jimmy.perchet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=peppe.cavallaro@st.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.