Date: Tue, 28 Aug 2012 03:24:24 -0600 From: PseudoCylon <moonlightakkiy@yahoo.ca> To: Anuranjan Shukla <anshukla@juniper.net> Cc: freebsd-net@freebsd.org Subject: Re: Proposal for changes to network device drivers and network stack (RFC) Message-ID: <CAFZ_MYJFK0-OC1HR=C4NePeTfDVJz1VnJi=Cj2buxbDw_FinCg@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
> ------------------------------
>
> Message: 2
> Date: Fri, 24 Aug 2012 21:11:45 -0700
> From: Anuranjan Shukla <anshukla@juniper.net>
> Subject: Proposal for changes to network device drivers and network
> stack (RFC)
> To: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
> Message-ID: <CC5C760E.18207%anshukla@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFZ_MYJFK0-OC1HR=C4NePeTfDVJz1VnJi=Cj2buxbDw_FinCg>