public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ed L Cashin <ecashin@coraid.com>
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ATA over Ethernet driver for 2.6.10-rc3-bk11
Date: Wed, 22 Dec 2004 08:19:50 -0500	[thread overview]
Message-ID: <87hdme31xl.fsf@coraid.com> (raw)
In-Reply-To: 1103356085.3369.140.camel@sfeldma-mobl.dsl-verizon.net

Scott Feldman <sfeldma@pobox.com> writes:

...
>> +static char aoe_iflist[IFLISTSZ];
>> +
>> +int
>> +is_aoe_netif(struct net_device *ifp)
>> +{
>> +       register char *p, *q;
>> +       register int len;
>> +
>> +       if (aoe_iflist[0] == '\0')
>> +               return 1;
>> +
>> +       for (p = aoe_iflist; *p; p = q + strspn(q, WHITESPACE)) {
>> +               q = p + strcspn(p, WHITESPACE);
>> +               if (q != p)
>> +                       len = q - p;
>> +               else
>> +                       len = strlen(p); /* last token in aoe_iflist
> */
>> +
>> +               if (strlen(ifp->name) == len && !strncmp(ifp->name, p,
> len))
>> +                       return 1;
>> +               if (q == p)
>> +                       break;
>> +       }
>> +
>> +       return 0;
>> +}
>
> This is getting called for every skb received.  Do you really want to
> walk a string array looking for "eth0" or "eth1" for every receive
> packet?  Maybe making the locals "register" helps speed things up.  :-)
>
> Seriously, can you achieve the same by registering the packet type
> handler for each dev and let netif_receive_skb() do the check for
> skb->dev == packet_type->dev?

We'd like to keep state in the driver in order to be able to control
both outgoing and incoming traffic.  I'm not sure this check will
become a performance problem, but anyone with who can measure it is
welcome to speak up.  I suspect that optimizing this now would be a
case of premature optimization.

>> + * (1) i have no idea if this is redundant, but i can't figure why
>> + * the ifp is passed in if it is.
>
> This isn't necessary - see deliver_skb()

Thanks.  That looks like the only place our packet handler is called.

>> +       skb->len += ETH_HLEN;   /* (2) */
>
> You want to do a skb_push(skb, ETH_HLEN) here instead to keep skb->len
> and skb->data corresponding (basically to undo the skb->pull() in
> eth_type_trans()).  skb->mac.raw will still be correct.

Thanks.

...
>> +       if (h->verfl & AOEFL_ERR) {
>> +               n = h->err;
>> +               if (n > NECODES)
>> +                       n = 0;
>> +               printk(KERN_CRIT "aoe: aoenet_rcv: error packet from
> %d.%d; "
>> +                       "ecode=%d '%s'\n",
>> +                      __be16_to_cpu(*((u16 *) h->major)), h->minor,
>> +                       h->err, aoe_errlist[n]);
>> +               goto exit;
>> +       }
>
> Is there a better way to handle errors than flooding the log?

These errors haven't happened much, but if they did, I'd want
everybody to know.  Would you suggest a per-device counter to limit
how many times this message gets printed?  

>> +       dev_kfree_skb(skb);
>
> kfree_skb() should be enough.

Hmm.  It's just a macro for kfree_skb, but I thought that
dev_kfree_skb is the more correct one for us to call.  I mean, if
dev_kfree_skb isn't supposed to be called here, then what's it for?

-- 
  Ed L Cashin <ecashin@coraid.com>


  parent reply	other threads:[~2004-12-22 13:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-17 15:38 [PATCH] ATA over Ethernet driver for 2.6.10-rc3-bk11 Ed L Cashin
2004-12-17 22:53 ` Greg KH
2004-12-18  7:48 ` Scott Feldman
2004-12-18  7:55   ` Jeff Garzik
2004-12-20 16:21   ` [PATCH] ETH_P_AOE (was Re: [PATCH] ATA over Ethernet driver for 2.6.10-rc3-bk11) Ed L Cashin
2004-12-21 18:54     ` Greg KH
2004-12-21 15:21   ` [PATCH] ATA over Ethernet driver for 2.6.10-rc3-bk11 Ed L Cashin
2004-12-22 13:19   ` Ed L Cashin [this message]
2004-12-22 13:55     ` Alan Cox
     [not found] <87k6rhc4uk.fsf@coraid.com.suse.lists.linux.kernel>
2004-12-18  9:11 ` Andi Kleen

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=87hdme31xl.fsf@coraid.com \
    --to=ecashin@coraid.com \
    --cc=linux-kernel@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