Proposal for changes to network device drivers and network stack (RFC)

[PseudoCylon]

> ------------------------------
>
> Message: 2
> Date: Fri, 24 Aug 2012 21:11:45 -0700
> From: Anuranjan Shukla <anshukla at juniper.net>
> Subject: Proposal for changes to network device drivers and network
>         stack (RFC)
> To: "freebsd-net at freebsd.org" <freebsd-net at freebsd.org>
> Message-ID: <CC5C760E.18207%anshukla at juniper.net>
> Content-Type: text/plain; charset="us-ascii"
>
> At Juniper Networks, we've been using FreeBSD to build JUNOS (Juniper's
> network operating system). So far the additions and changes to the
> functionality were made inline, making the task of upgrading to new
> versions of FreeBSD progressively difficult. We've been looking at JUNOS
> to see if we can build it off of a clean FreeBSD base rather than making
> changes to the OS inline. As part of that work, we've come up with a few
> expansive change proposals to FreeBSD kernel that will make this task
> possible for us, and hopefully also contribute something of interest to
> the community. If the community is in agreement with these, we'd like to
> contribute/commit them to FreeBSD.
>
> This is a proposal and an RFC. The actual nomenclature is open to ideas
> (naming etc). From Juniper, Marcel (marcel at freebsd.org) will be attending
> the upcoming DevSummit at Cambridge. He's indicated that interested folks
> are welcome to chat with him about this stuff during the summit.
>
> The changes we propose are (the code/diffs etc are indicated
> at the end of this email):
>
> - Network Device Drivers
> - Building FreeBSD kernel without network stack, network stack as a module
> - Changes to mbuf and socket structures (minor member additions)
>
> Network Device Drivers:
> -----------------------
> As we indicated during DevSummit 2012, JUNOS extended the interface
> functionality in a big way to support logical interfaces, interface
> hierarchies and scaling in general. Not surprisingly this resulted in
> changing the drivers to use our custom interface structure(s). A simple
> way to resolve this without impacting the rest of the large codebase is to
> avoid directly accessing (get/set) the ifnet structure from the drivers.
> Using get/set functions to update the functionality would make the driver
> more 'flexible' for the network stack to work with in situations where the
> stack wants to extend the interface functionality.
>
> For eg,
>
>  em_start_locked(struct ifnet *ifp, struct tx_ring *txr)
>  {
> -       struct adapter  *adapter = ifp->if_softc;
> +       struct adapter  *adapter = if_getsoftc(ifp);
>         struct mbuf     *m_head;
>
>         EM_TX_LOCK_ASSERT(txr);
>
> -       if ((ifp->if_drv_flags & (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) !=
> +       if ((if_getdrvflags(ifp) & (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) !=
>             IFF_DRV_RUNNING)
>                 return;
>
>         if (!adapter->link_active)
>                 return;
>
> -       while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) {
> +       while (!if_sendq_empty(ifp)) {
>                 /* Call cleanup if number of TX descriptors low */
>                 if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD)
>                         em_txeof(txr);
>                 if (txr->tx_avail < EM_MAX_SCATTER) {
> -                       ifp->if_drv_flags |= IFF_DRV_OACTIVE;
> +                       if_setdrvflagbits(ifp,IFF_DRV_OACTIVE, 0);
>                         break;
>                 }
> -                IFQ_DRV_DEQUEUE(&ifp->if_snd, m_head);
> +               m_head = if_dequeue(ifp);
>                 if (m_head == NULL)
>                         break;
>                 /*
> @@ -1010,7 +1009,7 @@ em_start_locked(struct ifnet *ifp, struct tx_ring
>                 if (em_xmit(txr, &m_head)) {
>                         if (m_head == NULL)
>                                 break;
> -                       IFQ_DRV_PREPEND(&ifp->if_snd, m_head);
> +                       if_sendq_prepend(ifp, m_head);
>                         break;
>
> This allows Juniper to have its own interface structure(s) instead of
> ifnet, and still be able to use the driver without modification. Since the
> notion of ifnet is abstracted away, other users can also find this useful
> in plugging in functionality without having muck around in the driver code.
>
> The ifnet split/restructuring was discussed in DevSummit at BSDCan in May
> 2012. This change can also aid in that work.
>

Non-attendees like me would better read the minutes before commenting
anything, but http://wiki.freebsd.org/201205DevSummit/Network
indicates the result is TBD. So, I will just dump my thought.

Wouldn't using prepossessor macro or hooking be more flexible? (Could
support multiple functionality.)

i.e.

#ifndef       LOOK_MA_NEW_IFNET
#define       IF_GETDRVFLAGS(f)       f->if_drv_flags
...
#else
#define       IF_GETDRVFLAGS(f)       new_getdrvflags(f)
...
#endif

or

       init somewhere
              ifp->if_getdrvflags = new_getdrvflags;
              ...

       and call
              if ((ifp->if_getdrvflags(ifp) & ...




AK